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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport System (ITS). 

The present document is part 4, sub-part 1 of a multi-part deliverable. Full details of the entire series can be found in 
part 1 [2]. 



Introduction 



The GeoNetworking protocol is a network layer protocol that provides packet routing in an ad hoc network. It makes 
use of geographical positions for packet transport. GeoNetworking supports the communication among individual ITS 
stations as well as the distribution of packets in geographical areas. 

GeoNetworking can be executed over different ITS access technologies for short-range wireless technologies, such as 
ITS-G5 and infrared. The ITS access technologies for short-range wireless technologies have many technical 
commonalities, but also differences. In order to reuse the GeoNetworking protocol specification for multiple ITS access 
technologies, the specification is separated into media-independent and media-dependent functionalities. 
Media-independent functionalities are those which are common to all ITS access technologies for short-range wireless 
communication to be used for GeoNetworking. These media-dependent functionalities extend the media-independent 
functionality for a specific ITS access technology. Therefore, the GeoNetworking protocol specification consists of the 
standard for media-independent functionality and at least one standard for media-dependent functionality. However, it 
should be noted that the media-dependent extensions do not represent distinct protocol entities. 
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1 Scope 

The present document specifies the media-independent functionahty of the GeoNetworking protocol. 



References 



References are either specific (identified by date of pubhcation and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI EN 302 665: "Intelligent Transport Systems (ITS); Communications Architecture". 

[2] ETSI TS 102 636-1: "Intelligent Transport Systems (ITS); Vehicular Communications; 

GeoNetworking; Part 1: Requirements". 

[3] ETSI TS 102 636-2: "Intelligent Transport Systems (ITS); Vehicular- Communications; 

GeoNetworking; Part 2: Scenarios". 

[4] ETSI TS 102 636-3: "Intelligent Transport Systems (ITS); Vehicular Communications; 

GeoNetworking; Part 3: Network architecture". 

[5] ETSI TS 102 636-5-1: "Intelligent Transport Systems (ITS); Vehicular Communications; 

GeoNetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol". 

[6] ETSI TS 102 636-6-1: "Intelligent Transport Systems (ITS); Vehicular Communications; 

GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over 
GeoNetworking Protocols". 

[7] ETSI EN 302 931: "Intelligent Transport Systems (ITS); Vehicular Communications; 

Geographical Area Definition". 

[8] ITU-T Recommendation X.691 (2002): "Information technology - ASN.l encoding rules: 

Specification of Packed Encoding Rules (PER)". 

[9] Annex to ITU Operational Bulletin No. 741 - 1.VI.200: "Complement To ITUT Recommendation 

E.212 (11/98)". 

NOTE: Available at: http://www.itu.int/ETUT/ . 

2.2 Informative references 

The following referenced documents are not necessary for the apphcation of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI ES 202 663: "Intelligent Transport Systems (ITS); European profile standard for the physical 

and medium access control layer of Intelligent Transport Systems operating in the 5 GHz 
frequency band". 
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[i.2] ETSI TS 102 636-4-2: "Intelligent Transport Systems (ITS); Vehicular Communications; 

GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to- 
multipoint communications; Sub-part 2: Media dependent functionalities for ITS-G5A media". 

[i.3] IEEE 802.3: "Ethernet Working Group". 

[i.4] IEEE 802. lip: "IEEE Standard for Local and Metropolitan Area Networks - Specific requirements 

Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications 
Amendment 6: Wireless Access in Vehicular Environments". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 302 665 [1], TS 102 636-3 [4], 
TS 102 636-6-1 [6] and the following apply: 

destination: receiver that processes a GeoUnicast packet and delivers it to upper protocol entities, but does not relay the 
packet to other GeoAdHoc routers 

forwarder: GeoAdhoc router that processes a packet and relays it to other GeoAdhoc routers 

GeoAdhoc router: Ad hoc router that implements the GeoNetworking protocol 

local position vector: position vector for the local GeoAdhoc router 

neighbour: GeoAdhoc router in direct (single-hop) communication range 

packet: GeoNetworking PDU 

position vector: position information of a GeoAdhoc router represented by a tuple of address, timestamp, geographical 
position, speed, heading and corresponding accuracy information 

receiver: GeoAdhoc router that processes a packet, delivers it's data to upper protocol entities and relays the packet to 
other GeoAdhoc routers 

sender: GeoAdhoc router that has sent the GeoNetworking packet 

source: GeoAdhoc router that originates a GeoNetworking packet 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

ALT Altitude 

ACC(POS, GN_ADDR) Accuracy of the position for the GeoAdhoc router GN_ADDR 

ACC(S , GN_ADDR) Accuracy of the speed for the GeoAdhoc router GN_ADDR 

ACC(H, GN_ADDR) Accuracy of the heading for the GeoAdhoc router GN_ADDR 

GEO_MAX Maximum size of the GeoNetworking packet header 

GEOSEC_MAX Maximum size of the optional GeoNetworking Security header 

H(GN_ADDR) Heading of the ITS station GN_ADDR 

LAT Latitude 

LL_ADDR Link layer address that identifies the ITS station at the link layer protocol entity in the 

ITS Access Layer 

LL_ADDR_NH Link layer address of the next hop 

LONG Longitude 

LS_PEND1NG Location Service pending flag 

LSB(LONG) LSB of the Longitude 

LSB(ALT) LSB of the Altitude 

LSB(TST) LSB of the Timestamp 

LSB(S) LSB of the Speed 
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LSB(H) 

M 

MRC 

MTU_AL 

POS(GN_ADDR) 

RAND[x,y] 

S(GN_ADDR) 

SN(GN_ADDR) 

SN_MAX 

SN(P) 

T(LocTE) 

TO_CBF_MIN 

TO_CBF_MAX 

TST(UET) 



LSB of the Heading 

Manual 

Maximum Retransmit Counter 

MTU of the ITS Access Layer 

Geographical position of the ITS station GN_ADDR 

Function that returns a random (integer) number in the given interval [x,y] 

Speed of the ITS station GN_ADDR 

Last maximum sequence number received from the GeoAdhoc router 

Largest possible value of the sequence number 

Value of the sequence number field carried in a GeoNetworking packet 

Lifetime of an entry in the location table 

Timeout; minimum duration a packet is buffered in the CBF cache 

Timeout; maximum duration a packet is buffered in the CBF cache 

Number of milliseconds since the Unix Epoch midnight (0 hour), January 1, 1970 



3.3 



Abbreviations 



For the purposes of the present document, the abbreviations given in EN 302 665 [1], TS 102 636-3 [4], 
TS 102 636-6-1 [6] and the following apply: 

Ace Accuracy 

BC Broadcast 

BTP Basic Transport Protocol 

BTP Basic Transport Protocol 

CBF Contention-Based Forwarding 

DE Destination 

ECS Frame Check Sequence 

FIFO First In First Out 

GAC Geographically-Scoped Anycast 

GBC Geographically-Scoped broadcast 

GF Greedy Forwarding 

GN GeoNetworking 

GN_ADDR GeoNetworking Address 

GN6ASL GeoNetworking to IPv6 Adaptation Sub-Layer 

GN6ASL GeoNetworking to IPv6 Adaptation Sub-Layer 

GN6-SDUGN6 Service Data Unot 

HL Hop Limit 

HST Header Sub-Type 

HT Header Type 

LL Link Layer 

LocT Location Table 

LocTE Location Table Entry 

LPV Local Position Vector 

LS Location Service 

LSB Least Significant Bit 

LT Lifetime 

MAC Medium Access Control 

MFR Most Forward within Radius 

MHVB Multi-Hop Vehicular Broadcast 

MID MAC ID 

MTU Maximum Transmit Unit 

NH Next Header 

PCI Protcol Control Information 

PCI Protocol Control Information 

PDU Protocol Data Unit 

PL Payload Length 

POS Position 

PV Position Vector 

PV Position Vector 

RTC Retransmit Counter 

sec Station Country Code 



£75/ 



11 



ETSI TS 102 636-4-1 VI. 1.1 (2011-06) 



SE 


Sender 


SHB 


Single Hop Broadcast 


SN 


Sequence Number 


SO 


Source 


SPV 


Short Position Vector 


SST 


Station Subtype 


ST 


Station Type 


TSB 


Topologically Scoped Broadcast 


T-SDU 


Transport Service Data Unit 


TST 


Timestamp 


UC 


Unicast 


UET 


UNIX Epoch Time 



4 Services provided by the GeoNetworking protocol 

The GeoNetworking protocol is a network protocol that resides in the ITS network and transport layer [1] and is 
executed in the ad hoc router [4], specifically in the GeoAdhoc router. It provides the transport of packets in the ITS ad 
hoc network [4]. It shall support the requirements specified in [2] and the scenarios specified in [3]. 

The GeoNetworking protocol provides services to upper protocol entities, i.e. the ITS Transport Protocol, such as the 
Basic Transport Protocol (BTP) [5], and the GeoNetworking to IPv6 Adaptation Sub-Layer (GN6ASL) [6]. The 
services are provided via the GN_SAP using service primitives of different types that carry parameters and the PDU of 
the upper protocol entity, i.e. T/GN6 PDU (see figure 1). A PDU of the transport protocols are considered as SDU in the 
GeoNetworking protocol. The SDU is complemented with Protocol Control Information (PCI) and transmitted as 
GN PDU to the peer entity. 

In order to provide its packet transport services, the GeoNetworking protocol uses the services of the ITS Access Layer. 



£75/ 



12 



ETSI TS 102 636-4-1 VI. 1.1 (2011-06) 



Other 

Transport 

Protocols 



ITS Basic 
Transport 
Protocol 
(BTP) 



TPDU 



GeoNetworking 
IPv6 Adaptation 
Sub-Layer 
(GN6ASL) 



GN6PDU 



GN SAP 



ITS 

Network 

and Transport 

Management 



GN_ 

Mgmt_ 

SAP 



GeoNetworking 
Protocol 



T/GN6 
PCI 



T/GN6 
SDU 



GN PDU 



PCI 



T/GN6 
SDU 



ITS Network 

und Transport 

Layer 



IN SAP 



Link Layer 
Protocol 



ITS Access 

Technologies 

Layer 



Figure 1 : Service primitives, SDUs and PDUs relevant for the GeoNetworking protocol 

The present document specifies the internal GN_SAP between the GeoNetworking protocol and the ITS transport 
protocol, such as the Basic Transport Protocol (BTP) [5]), the GeoNetworking IPv6 Adaptation Sub-Layer (GN6ASL) 
as defined in [6] and other transport protocols as well as the GN_Mgmt_SAP between the GeoNetworking protocol and 
the ITS Network and Transport Management. 



5 Format convention 

The basic convention for the specification of packet formats is illustrated in figure 2. The bits are grouped into bytes. 
The bits of an octet are always shown horizontally and are numbered from to 7. Up to 4 octets are shown horizontally; 
multiple sets of 4 octets are grouped vertically. Octets are numbered from 1 to N. 

The octets are transmitted in ascending numerical order; inside an octet the bit is transmitted first. 

When a field is contained within a single octet, the highest bit number of the field represents the lowest order value, 
i.e. the Least Significant Bit (LSB). 

When a field spans more than one octet, the order of bit values within each octet progressively increases as the octet 
number increases, i.e. the highest bit number of the multi-octet field represents the LSB. 
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12 3 

012345670123456701234567012345 6 7 



Octet 


1 Octet 1 1 Octet 2 


1 Octet 3 


Octets 4 to 7 


1 Octet N-1 


Figure 2: Format convention 



GeoNetworking address 



6.1 General 

Every GeoAdhoc router shall have a unique GeoNetworking address. This address shall be used in the header of a 
GeoNetworking packet and identify the communicating GeoNetworking entities. 

6.2 GeoNetworking address format 

The format of the GeoNetworking address is described in figure 3. 







12 3 4 


5 e 


1 
7 1 


2 3 4 


5 
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2 

1 


3 

2 3 4 5 6 7 1 


2 3 4 5 6 7 


M 


ST 


SS 

T 


sec 


MID 


MID 



Figure 3: GeoNetworiting address format 

6.3 Fields of the GeoNetworking address 

The GeoNetworking address shall be comprised of the fields specified in table 1 . 
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Table 1 : Fields of the GeoNetworking address 



Field # 


Field name 


Octet/bit position 


Type 


Description 


First 


Last 


1 


M 


Octet 
BitO 


Octet 
BitO 


1 bit unsigned integer 


This bit allows distinguishing between 
manually configured network address and the 
initial GeoNetworking address. IVI is set to 1 if 
the address is manually configured otherwise 
it equals 0. 


2 


ST 


Octet 
Bit1 


Octet 
Bit 4 


4 bit unsigned integer 


ITS Station Type. 

To identify the ITS Station type. 

Bit 1: 

- Vehicle ITS station. 

1 - Roadside ITS station. 
Bit 2 to Bit 4: 

For Roadside ITS station: 

- Traffic light. 

1 - Ordinary Roadside ITS station. 
For Vehicle ITS station: 

- Bike. 

1 - Motorbike. 

2 - Car. 

3 - Truck. 

4 - Bus. 


3 


SST 


Octet 
Bits 


Octet 
Bits 


1 bit unsigned integer 


ITS Station sub-type. 

To distinguish between public transport and 

private ITS stations. 

- Public (e.g. school bus, public safety 
vehicle). 

1 - Private (e.g. non-public transport 
vehicle). 


4 


sec 


Octet 
Bite 


Octet 1 
Bit? 


10 bit unsigned integer 


ITS Station Country Code. 


S 


MID 


Octet 2 


Octet 7 


48 bit address 


This field represents the LL ADDR. 



The first bit is reserved for the recognition of manual configured GeoNetworking addresses. The allocation of ITS 
Station Country Codes (SCC) is administered by the ITU-T [9]. 

The MID field corresponds to the access layer address. In case of IEEE 802. lip [i.4] MAC layer, the 48-bit MAC layer 
address shall be used. 

In order to allow for the resolution of a GeoUnicast destination GN_ADDR from an IPv6 destination address using 
virtual interfaces of type Ethernet V2.0/IEEE 802.3 LAN, the GeoNetworking address space shall remain 48-bit wide 
(size of the MID field in the GeoNetworking address). In particular, as described in TS 102 636-6-1 [6], table 1, note 1, 
the GN6ASL resolves an MID from a unicast destination IPv6 address and passes it to GeoNetworking via the 
GN-DATA.request primitive (clause H.2). Then, the GeoNetworking protocol entity is responsible for deriving a full 
GN_ADDR from the MID. This full GN_ADDR shall be derived from a LocTE (if it exists) or by executing the 
Location Service with Request GN_ADDR field containing only the MID part and the other bits set to 0. 

To be compliant with the IPv6 over GeoNetworking architecture, the GeoNetworking address space shall remain 48-bit 
wide (size of the MID field in the GeoNetworking address) in order to provide a virtual interface of Ethernet type to 
IPv6 layer and to perform the forwarding via GeoNetworking in a transparent way (see TS 102 636-6-1 [6]). 

If the address is updated for privacy reasons, i.e. by assignment of a short-term identity, only the last field of the address 
shall be updated and derived from the short-term identity (pseudonym). 
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7 Data structures 

7.1 Location table 

7.1.1 General 

A GeoAdhoc router shall maintain a local data structure, referred to as location table (LocT). This data structure holds 
information about other ITS stations that execute the GeoNetworking protocol. The data elements of a location table 
entry is specified in clause 7.1.2 and the maintenance of the location table in clause 7.1.3. 

7.1 .2 Minimum data elements of a Location Table Entry 

A Location Table Entry (LocTE) shall contain at least the following data elements: 

• GeoNetwork address of the ITS station GN_ADDR. 

• LL address of the ITS station LL_ADDR. 

• Type of the ITS station (vehicle ITS station, roadside ITS station). 

• Position vector, i.e. Long Position Vector (clause 8.4.2), of the ITS station, comprised of: 

Geographical position POS(GN_ADDR). 

Speed S(GN_ADDR). 

Heading H(GN_ADDR). 

Timestamp of the geographical position TST(POS, GN_ADDR). 

Accuracy of the geographical position Acc(POS, GN_ADDR). 

Accuracy of the speed Acc(S, GN_ADDR). 

Accuracy of the heading Acc(H, GN_ADDR). 

• Flag LS_PENDING(GN_ADDR): Flag indicating that a Location Service (LS) (clause 9.2.4) is in progress. 

• Flag IS_NEIGHBOUR(GN_ADDR): Flag indicating that the GeoAdhoc router is in direct communication 
range, i.e. is a neighbour. 

• Sequence number SN(GN_ADDR): The sequence number of the last packet from the source GN_ADDR that 
was identified as 'not duplicated'. 

NOTE 1 : The LocTE can contain more data elements defined in media-dependent functionalities of 
GeoNetworking. 

NOTE 2: The format of the data in the LocT is implementation-specific and, therefore, not further specified. 

NOTE 3: LS_PENDING(GN_ADDR) equals TRUE indicates that for the GN_ADDR a location service has been 
invoked and is in process. 

7.1 .3 Maintenance of the Location Table 

The entries in the location table shall be soft-state, i.e. entries are added with a lifetime T(LocTE) set to the value of the 
MIB attribute itsGnLifetimeLocTE and shall be removed when the lifetimes expires. 
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7.2 Local Position Vector 

7.2.1 General 

A GeoAdhoc router shall maintain a local data structure that holds position-related information for the local GeoAdhoc 
router, i.e. the local position vector LPV. The data elements of a location table entry is specified in clause 7.2.2 and the 
maintenance of the location table in clause 7.2.3. 

7.2.2 IVIinimum data elements 

The LPV shall contain at least the following data elements: 

• Geographical position POS_LPV. 

• Speed S_LPV. 

• Heading H_LPV. 

• Timestamp TST_LPV indicating when the geographical position POS_LPV was generated. 

• Accuracy of the geographical position Acc(POS, LPV). 

• Accuracy of the speed A CC (S, LPV). 

• Accuracy of the heading ACQH, LPV). 

7.2.3 IVIaintenance 

At start-up, all data elements of the LPV shall be initialized with to indicate an unknown value. 

The LPV should be updated with a minimum frequency of the MIB attribute itsGnMinimumUpdateFrequencyLPV. 

If the LPV is updated with a smaller frequency, the GeoAdhoc router shall not handle GeoNetworking packets. 

NOTE: The MIB attribute itsGnMinimumUpdateFrequencyLPV should have different values for vehicle ITS 
station and roadside ITS station. This reflects the fact that roadside ITS stations are not mobile, but at 
most portable, and therefore require a smaller update frequency. 

7.3 Sequence number 

7.3.1 General 

Each GeoAdhoc router shall maintain a local sequence number that determines the Sequence Number (SN) field of the 
next GeoNetworking packet to be transmitted. 

7.3.2 IVIaintenance 

SN shall be initialized to 0. For every GeoNetworking packet P, the sequence number SN(P) shall be incremented as 
follows: 

SN{P) = {SN(P) + 1) mod SN _ MAX 

with SN(P) being the sequence number of the GeoNetworking packet and SN_MAX the largest possible sequence 
number. The resulting sequence number shall be included in the GeoNetworking packet. 

The SN is incremented for multi-hop GeoNetworking packets only. Single-hop GeoNetworking packets (BEACON, 
SHB) do not carry a SN field. 
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7.4 Location service packet buffer 

7.4.1 General 

Upon invocation of the LS (clause 9.2.4), a GeoAdhoc router shall queue a GeoNetworking packet in a LS packet buffer 
for the sought destination until the LS is completed. Subsequent GeoNetworking packets, which are processed while the 
LS is in progress, shall also be buffered (see clause 9.2.4). 

7.4.2 IVIaintenance 

The LS packet buffer shall have a minimum size of the value stored in the MIB attribute 
itsGnLocationServicePacketBufferSize. 

The LS packet buffer shall work as follows: 

• GeoNetworking packets arriving at the LS packet buffer for a destination (GN_ADDR of a certain ITS station) 
shall be queued at the tail of the queue. 

• When a new GeoNetworking packet arrives at the LS packet buffer and exceeds the buffer capacity (buffer 
overflow), GeoNetworking packets from the head of the queue are removed and the new GeoNetworking 
packet queued at the tail (head drop). 

• When the LS is completed, the LS packet buffer shall be flushed, i.e. all GeoNetworking packets stored in the 
buffer shall be sent in a First-In-First-Out (FIFO) manner. 

• When the queuing time of the GeoNetworking packet in the LS packet buffer exceeds the packet lifetime 
carried in the GeoNetworking packet's LT field in the Extended Header, the GeoNetworking packet shall be 
discarded. 

• When a stored GeoNetworking packet is sent, the LT field shall be reduced by the queuing time in the LS 
packet buffer. 

• When the LS does not complete, all stored GeoNetworking packets shall be discarded triggered by the LS. 
NOTE: The mechanism to detect that a LS does not complete is implementation dependent. 

7.5 Forwarding packet buffer 

7.5.1 General 

A GeoAdhoc router shall ust forwarding packet buffers to temporarily keep packets in a GeoAdhoc router during the 
forwarding process. 

A GeoAdhoc router shall maintain the foUowing/onvarii/n^ packet buffers: 

• UC forwarding packet buffer to buffer GeoUnicast packets per GN_ADDR. 

• BC forwarding packet buffer to buffer TSB, GeoBroadcast and GeoAnycast packets. 

If Contention-Based Forwarding (CBF) is enabled, i.e. MIB attribute itsGnGeoUnicastForwardingAlgorithm set to 2 
(CBF), the GeoAdhoc router shall maintain a CBF packet buffer per packet. 

7.5.2 Buffer size 

The UC forwarding packet buffer shall have a minimum size given by the value of the MIB attribute 
itsGnUcForwardingPacketBufferSize. 

The BC forwarding packet buffer shall have a minimum size given by the value of the MIB attribute 
itsGnBcForwardingPacketBufferSize. 
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The CBF packet buffer shall have a minimum size given by the value of the MIB attribute itsGnCbfPacketBufferSize. 

7.5.3 Maintenance 

The UC forwarding packet buffer and the BC forwarding packet buffer shall work as follows: 

• GeoNetworking packets arriving at the forwarding packet buffer shall be queued at the tail of the queue. 

• When a new GeoNetworking packet arrives at the forwarding packet buffer and exceeds the buffer capacity, 
GeoNetworking packets from the head of the queue are removed and the new GeoNetworking packet queued 
at the tail (head drop). 

• When the forwarding packet buffer is flushed, the GeoNetworking packets stored in the buffer shall be 
forwarded in a FIFO manner. 

• When the queuing time of the GeoNetworking packet in the forwarding packet buffer exceeds the packet 
lifetime carried in the packet's LT field in the Extended Header, the GeoNetworking packet shall be discarded. 

• When a stored GeoNetworking packet is sent, the value of the LT field shall be reduced by the queuing time in 
the forwarding packet buffer. 

The CBF packet buffer shall work as follows: 

• Packets arriving at the CBF packet buffer shall be queued at the tail of the queue. 

• When a new GeoNetworking packet arrives at the CBF packet buffer and exceeds the buffer capacity, 
GeoNetworking packets from the head of the queue are removed and the new GeoNetworking packet queued 
at the tail (head drop). 

• Every GeoNetworking packet in the buffer is associated with a timer. When the timer expires the 
GeoNetworking packet is removed from the queue. 

NOTE: The value of the timer is set by the CBF forwarding algorithm specified in clause C.3. 

8 GeoNetworking packet structure and formats 

8.1 Overview 

This clause specifies the structure and the format of the GeoNetworking packet. 

8.2 Packet structure 

8.2.1 General 

As specified in TS 102 636-3 [4], the GeoNetworking protocol shall either be used in the GeoNetworking protocol stack 
(TS 102 636-3 [4], clause 7.3.2) or in the protocol stack that combines the GeoNetworking protocol and IPv6 
(TS 102 636-3 [4], clause 7.3.4). 

8.2.2 Overall structure 

A GeoNetworking packet is part of the overall frame/packet structure depicted in figure 4: 

• The MAC header is the header of the MAC protocol of the ITS access technology. The MAC protocol can add 
additional protocol elements, such as a trailer for the MAC FCS as in ITS-G5 [i.l]. 

NOTE 1: The MAC header is not specified by the present document. However, the GeoNetworking protocol sets 

the MAC address, or more generally the link-layer address, in order to define and identify the next hop of 
a GeoNetworking packet. 
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• The GeoNetworking header is the header of the GeoNetworking packet as defined in the present document and 
extended for media-dependent GeoNetworking functionahty, such as for ITS-G5A specified in 

TS 102 636-4-2 [i.2]. 

• The optional GeoNetworking security header. 

NOTE 2: The specification of the GeoNetworking security header is outside the scope of the present document. 

• The optional payload represents the user data that are created by upper protocol entities, i.e. the T-SDU or 
GN6-SDU. It is passed to the GeoNetworking protocol entity for transmission. 

NOTE 3: The general packet structure is shown as seen by the MAC protocol of the ITS Access Layer. 

NOTE 4: Some GeoNetworking packet do not carry a payload, such as Beacon. 



MAC 
Header 


LLC Header 


GeoNetworking 
Header 


GeoNetworking 

Security 

Header 

(optional) 


Payload 
(optional) 



Figure 4: GeoNetworking pacltet structure 

8.2.3 Maximum Transmit Unit 

The Maximum Transmit Unit (MTU), which the GeoNetworking protocol supports via the GN_SAP, i.e. the MTU_GN 
depends on the MTU of the access layer technology (MTU_AL) over which the GeoNetworking packet is transported. 
In particular, MTU_GN shall be less or equal to MTU_AL reduced by the size of the largest GeoNetworking protocol 
header (GEO_MAX) and by the size of the largest GeoNetworking Security header (GEOSEC_MAX): 

MTU _GN< MTU _AL- GEO _ MAX - GEOSEC _ MAX 

GEO_MAX is set by the MIB attribute itsGnMaxGeoNetworkingHeaderSize. 
The value of GEOSEC_MAX is beyond the scope of the present document. 

8.3 GeoNetworking lieader structure 

The GeoNetworking header shall be comprised of a Common Header and an Extended Header (figure 5). 



Common 
Header 


Extended 
Header 



Figure 5: GeoNetworl<ing header structure 

Common Header and Extended Header are specified in clauses 8.5 and 8.6, respectively. 



8.4 



Position vector 



8.4.1 Overview 

For simplicity, a set of position-related fields of the GeoNetworking header are subsumed to a position vector (PV). 
Two types of PV are defined: 

• Long position vector. 

• Short position vector. 
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8.4.2 Long Position Vector 
8.4.2.1 Structure 

The Long Position Vector shall consist of the fields specified in figure 6. 
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Figure 6: Long Position Vector 
8.4.2.2 Fields 

The Long Position Vector shall consist of the fields as specified in table 2. 

Table 2: Fields of Long Position Vector 



Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


GN_ADDR 


Octet 


Octet 7 


64 bit 
address 


n/a 


The network address for the GeoAdhoc router 
entity in the ITS station. 


2 


TST 


Octet 8 


Octet 1 1 


32 bit 

unsigned 

integer 


[ms] 


Expresses the time in milliseconds at which 
the latitude and longitude of the ITS station 
were acquired by the GeoAdhoc router. The 
time is encoded as: 

TST = TST(UET) mod 2^^ 

where TST(UET) is the number of milliseconds 
since the Unix Epoch 1970-01-01100:00. 


3 


Lat 


Octet 1 2 


Octet 1 5 


32 bit signed 
integer 


[1/10 micro- 
degree] 


WGS-84 latitude of the GeoAdhoc router 
expressed in 1/10 micro degree. 


4 


Long 


Octet 1 6 


Octet 1 9 


32 bit signed 
integer 


[1/10 micro- 
degree] 


WGS84 longitude of the GeoAdhoc router 
expressed in 1/10 micro degree. 


5 


S 


Octet 20 


Octet 21 


16 bit signed 
integer 


[1/100 m/s] 


Speed of the GeoAdhoc router expressed in 
signed units of 0,01 meters per second. 


6 


H 


Octet 22 


Octet 23 


16 bit 

unsigned 

integer 


[1/10 
degrees] 


Heading of the GeoAdhoc router from which 
the Network Header originates, expressed in 
unsigned units of 0,1 degrees from North 


7 


Alt 


Octet 24 


Octet 25 


16 bit signed 
integer 


[m] 


Altitude of the GeoAdhoc router expressed in 
signed units of 1 meter. 


8 


TAcc 


Octet 26 
BitO 


Octet 26 
Bit 3 


4 bit 

unsigned 

integer 


n/a 


Accuracy indicator for the value expressed in 
the field TST. The accuracy interval of the 
95 % accuracy level for the value of the TST 
field defined as: 

Accuracyg„c =Valueof (LSbit(TST)-2^'^''''' =lm.s-2^'*"' 

The minimum and maximum value of the time 
accuracy interval is then: 

lmiX2°-'^=1...32 768m.9. 
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Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


9 


PosAcc 


Octet 26 
Bit 4 


Octet 26 
Bit 7 


4 bit 

unsigned 

integer 


n/a 


Encoded accuracy indicator for the value of 
the position POS. The accuracy interval of the 
95 % accuracy level for POS is defined as: 

Accuracy^^^ = Area(POS,R) 

with 

POS = Lat, Long 

and 

R = LSbit(Long)-2'"'"^'' 

PosAcc = 0000 is reserved to indicate that no 
specific accuracy interval is specified. The 
maximum error the 95 % accuracy interval can 
cover, represented by PosAcc = 1 1 1 1 , is 1/1 
micro degree * 2^^ equivalent to about 365 m. 
(see notes 1 to 3) 


10 


SAcc 


Octet 27 
BitO 


Octet 27 
Bit 2 


3 bit 

unsigned 

integer 


n/a 


Encoded accuracy indicator for the value 
expressed in the field Speed S. The accuracy 
interval of the 95 % accuracy level for the 
currently reported value is defined as: 

Accumcygs% =Valueof(LShit(S))-2^'^'"' = 0.01m /.s-2^''''' 

SAcc = 00 is reserved to indicate that the 
accuracy interval is not specified. The 
maximum error the 95 % accuracy interval can 
cover, represented by SAcc = 1 1 1 , is 
0,01 m/s * 2^ equivalent to 0,01 m/s * 128 = 
1 ,28 m/s. 


11 


HAcc 


Octet 27 
Bit 3 


Octet 27 
Bits 


3 bit 

unsigned 

integer 


n/a 


Encoded accuracy indicator for the value of 
the field Heading H. The interval of the 95 % 
accuracy level for the currently Heading value 
H is defined as: 

Accuracy^^cf^ =Valueof(LSbit(H))-2"^" = 0.005493247 deg ■ 2""" 

HAcc = 000 is reserved to indicate that no 
specific accuracy interval is specified. The 
maximum error the 95 % accuracy interval can 
cover, represented by the HAcc = 1 1 1 , is 
0,005493247 deg * 2 equivalent to about 
0,005493247 deg * 128 = 0,7 deg. 


12 


AltAcc 


Octet 27 
Bite 


Octet 27 
Bit 7 


2 bit 

unsigned 

integer 


n/a 


Encoded accuracy indicator for the value in the 
field Altitude {Alt). The accuracy interval of the 
95 % accuracy level is defined as: 

Accuracy 95% = 

Valueof (LSbit(Alt)) ■ 2'^'^'' = 

\m ■ 2^"' 
AltAcc = 00 is reserved to indicate that no 
specific accuracy interval is specified. The 
maximum error the 95 % accuracy interval can 
cover, represented by AltAcc='\ 1 , is 1 m * 2^ 
equivalent to about 1 m * 8 = 8 m. 


NOTE 1 : The least significant bit (LSB) of the Longitude LSbit(Long) represents the smallest encoded unit of the 

Longitude. 
NOTE 2: Packets with Latitude and Longitude information and a PosAcc =1111 shall receive special treatment whenever 

used. 
NOTE 3: The geographic extend of the area defined by (POS, R) is invariant with respect to the location of the center of 

the area on the Earth. 



£75/ 



22 



ETSI TS 102 636-4-1 VI. 1.1 (2011-06) 



8.4.3 Short Position Vector 
8.4.3.1 Structure 

The Short Position Vector shall consist of the fields specified in figure 7. 
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Figure 7: Sftort Position Vector 
8.4.3.2 Fields 

The S'/zort Position Vector shall consist of the fields as specified in table 3. 

Table 3: Fields of Stiort Position Vector 



Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


GN_ADDR 


Octet 


Octet 7 


64 bit 
address 


n/a 


The GAL'^DDf? field as specified in table 2. 


2 


TST 


Octet 8 


Octet 1 1 


32 bit 

unsigned 

integer 


[ms] 


The Timestamp TST field as specified in 
table 2. 


3 


Lat 


Octet 12 


Octet 1 5 


32 bit signed 
integer 


[1/10 micro- 
degree] 


The Latitude [Lat) field as specified in table 2. 


4 


Long 


Octet 16 


Octet 1 9 


32 bit signed 
integer 


[1/10 micro- 
degree] 


The Longitude {Long) field as specified in 
table 2. 



NOTE 1 : The short position vector does not have an altitude field. 

NOTE 2: The timestamp TST field indicates the time when the position (LAT, LONG) of the SPV was acquired. 



8.5 



Common Header 



8.5.1 Composition of tine Common Header 

The common header shall be present in every GeoNetworking packet and consists of the fields as depicted in figure 8. 

12 3 

01 23456701 23456701 23456701 234567 



Version 
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HT 


1 HST 


Reserved 


Flags 


PL 


TC 


HL 










SE 


PV 







Figure 8: Common Header format 
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8.5.2 Fields of the Common Header 

The Common Header shall carry the fields as specified in table 4. 



Bit to 5: 

Bit 6: itsGnStationType (IVIIB attribute) 

Bit 7: 



Only Bit 6 used. Other fields reserved for future use. 



Table 4: Fields of the Common Header 



Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


Version 


Octet 
BitO 


Octet 
Bit 3 


4 bit 

unsigned 

integer 


n/a 


Identifies the version of the GeoNetworking 
protocol. 


2 


NH 


Octet 
Bit 4 


Octet 
Bit 7 


4 bit 

unsigned 

integer 


n/a 


Identifies the type of header immediately 
following the GeoNetworking header as 
specified in table 5. 


3 


HT 


Octet 1 
BitO 


Octet 1 
Bit 3 


4 bit 

unsigned 

integer 


n/a 


Identifies the type of the GeoAdhoc header 
type as specified in table 6. 


4 


HST 


Octet 1 
Bit 4 


Octet 1 
Bit 7 


4 bit 

unsigned 

integer 


n/a 


Identifies the sub-type of the GeoAdhoc 
header type as specified in table 6. 


5 


Reserved 


Octet 2 


Octet 2 




n/a 


Reserved for media-dependent functionality. 


6 


Flags 


Octet 3 


Octet 3 


Bit field 


n/a 


Bit to 5: Reserved. Set to 0. 
Bit 6: Type if ITS station. 
Bit 7: Reserved. Set to 0. 


7 


PL 


Octet 4 


Octet 5 


16 bit 

unsigned 

integer 


[bytes] 


Length of the Network Header payload, i.e. the 
rest of the packet following the whole 
GeoNetworking header in octets. 


8 


TC 


Octet 6 


Octet 6 


Four sub- 
fields: 
Ibit 
unsigned 
integer, 

3 bit 

unsigned 

integer, 

2 bit 

selector, 

2 bit selector 


n/a 


Traffic class that represents Facility-layer 
requirements on packet transport. Composed 
of four sub-fields (figure 9): 
Bit 0: Reserved. Set to 0. 
Bit 1 to 3: Relevance 
Relevance expresses the relevance or 
importance of a message given by the upper 
protocol entity. The relevance of a message 
shall be encoded as defined in clause 8.5.6.1 . 

Bit 4 to 5: Reliability 

Reliability means the relative probability of 
correctly receiving a packet in a geographical 
area encoded by a 2 bit selector as detailed in 
table 7. 

Bit 6 to 7: Latency 

Latency expresses the relative packet delivery 
latency in a geographical area encoded by a 
2 bit selector as detailed in table 8. 


9 


HL 


Octet 7 


Octet 7 


8 bit 

unsigned 

integer 


[hops] 


Decremented by 1 by each GeoAdhoc router 
that forwards the packet. The packet must not 
be forwarded if Hop Limit is decremented to 
zero. 


10 


SEPV 


Octet 8 


Octet 35 


Long 
Position 
Vector 


n/a 


Long position vector of the sender. It shall 
carry the fields as specified in clause 8.4.2 
(Long Position Vector). 
Length: 28 octets. 
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8.5.3 Encoding of the NH field 

For the Next Header (NH) field in the Common Header the values as specified in table 5 shall be used. 
Table 5: Next Header (NH) field in the GeoNetworking Common Header 



Next Header (NH) 


Encoding 


Description 


ANY 





Unspecified 


BTP-A 


1 


Transport protocol (BTP-A for interactive packet 
transport) as defined in TS 102 636-5-1 [5] 


BTP-B 


2 


Transport protocol (BTP-B for non-interactive packet 
transport) as defined in TS 102 636-5-1 [5] 


IPv6 


3 


IPv6 header as defined in TS 102 636-6-1 [6] 



8.5.4 Encoding of tine HT and HST fields 

For the Header Type (HT) and the Header Sub-Type (HST) fields in the Common Header the values as specified in 
table 6 shall be used. 

Table 6: GeoNetworking Header Types and Header Sub-Types 



Header Type (HT) 


Header Sub-type (HST) 


Encoding 


Description 


ANY 







Unspecified 


UNSPECIFIED 





Unspecified 


BEACON 




1 


Beacon 


UNSPECIFIED 





Unspecified 


GEOUNICAST 




2 


GeoUnicast 


UNSPECIFIED 





Unspecified 


GEOANYCAST 




3 


Geographically-Scoped Anycast (GAG) 


GEOANYCAST CIRCLE 





Circular area 


GEOANYCAST RECT 


1 


Rectangular area 


GEOANYCAST ELIP 


2 


Ellipsoidal area 


GEOBROADGAST 




4 


Geographically-Scoped broadcast (GBC) 


GEOBROADGAST CIRCLE 





Circular area 


GEOBROADGAST RECT 


1 


Rectangular area 


GEOBROADGAST ELIP 


2 


Ellipsoidal area 


TSB ^^^^^ 




5 


Topologically-scoped broadcast (TSB) ■ 


SINGLE HOP 





Single-hop broadcast (SHB) 


MULTI HOP 


1 


Multi-hop TSB 


LS 




6 


Location service (LS) 


LS REQUEST 





Location service request 


LS REPLY 


1 


Location service reply 



8.5.5 Composition of the TC field 

The TC field shall consist of the fields as depicted in figure 9. 

12 3 



Reserved 



Relevance 



Reliability | Latency 



Figure 9: Traffic Class (TC) field composition 

The TC subfields are defined as relative values; i.e. they are not based on quantities. 

NOTE: The usage of the TC field is further specified in the media-dependent functionality of GeoNetworking 
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8.5.6 Encoding of the TC-sub-fields 

8.5.6.1 Encoding of the TC-sub-field Relevance 

The relevance of a message shall be encoded to a value in the range between and 7. The most relevant messages have 
the relevance value and the least relevant messages have the value 7. 

The default value for the TC sub-field Relevance field is set by the MIB attribute itsGnTrafficClassRelevance. 

8.5.6.2 Encoding of the TC-sub-field Reliability 

The reliability of a message shall be encoded as specified in table 7. 

The default value for the TC sub-field Reliability field is set by the MIB attribute itsGnTrafficClassReliability. 

NOTE: So far, Reliability is only defined for dissemination of a packet in a geographical area. For other 
forwarding types (e.g. GeoUnicast), the field is ignored. Same holds for Latency in clause 8.5.6.3. 

Table 7: Encoding of the Traffic Class (TC) sub-field Reliability 





00 


01 


10 


11 


Reliability 


Very high 


High 


Medium 


Low 



8.5.6.3 Encoding of the TC-sub-field Latency 

The TC sub-field Latency shall be encoded as specified in table 8. 

The default value for the TC sub-field Latency field is set by the MIB attribute itsGnTrafficClassLatency. 

Table 8: Encoding of the TC sub-field Latency 





00 


01 


10 


11 


Latency 


Very low 


Low 


IVIedium 


High 



8.5.7 Encoding of the LT field in Extended Headers 

The Lifetime (LT) field shall indicate the maximum tolerable time a packet can be buffered until it reaches its 
destination. 

NOTE: This parameter is relevant for safety and traffic efficiency information that do not have strict real-time 
requirements. In sparse network scenarios, this lifetime can also be used to avoid re-transmission and 
forwarding of outdated information. 

The following method for encoding of the LT field uses a non-linear encoding, which provides a high resolution for low 
numbers and progressively lower resolution for higher numbers. 

The LT field shall be comprised of two sub-fields: a LTMuMpUer sub-field (Multiplier) and a LTsase sub-field (Base) 
(figure 10) and shall be encoded as follows: 

Lifetime j^^gj^^ — Ll^^i^-^n^^ ■ Ll^^^^ 

The LT Base sub-field represents a two bit unsigned selector that chooses one out of four predefined values as specified in 
table 9. 
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Table 9: Encoding of Z. 7 sub-field LT Base 



Value 


LTbase 





50 ms 


1 


1 s 


2 


10s 


3 


100 s 



The LTMuMpUer is a 6 bit unsigned integer, which represents a muhipHer range from 1 to 2 - 1 = 63. The default value 
is 0, indicating no special requirement on the lifetime of the packet. The maximum lifetime is 6 300 s. 






1 2 3 
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6 7 


Multiplier [1.. 64] 


Base: 50 ms, 1 s, 10 s, 
100 s 



Figure 10: Composition of the LT field 

8.6 GeoNetworking packet headers 

8.6.1 Overview 

The GeoNetworking packet header shall be present in the every GeoNetworking packet: 
GeoUnicast (clause 8.6.2). 
TSB (clause 8.6.3). 
SHB (clause 8.6.4). 

GeoBroadcast and GeoAnycast (clause 8.6.5). 
BEACON (clause 8.6.6). 
LS Request and LS Reply (clauses 8.6.7 and 8.6.8). 

8.6.2 GeoUnicast packet ineader 

8.6.2.1 Composition of the GeoUnicast packet header 

The GeoUnicast header shall be comprised of the Common Header and the Extended Header as shown in figure 1 1 . 
NOTE: The Extended Header comprises all fields except the Common Header. 
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Figure 11 : Packer header format: GeoUnicast 



£75/ 



27 

8.6.2.2 Fields of the GeoUnicast packet header 

The GeoUnicast packet header shall consist the fields as specified in table 10. 

Table 10: Fields of the GeoUnicast packet header 
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Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


Common 
Header 


Octet 


Octet 35 


Common 
Header 


n/a 


Common lieader as specified in clause 8.5. 


2 


SN 


Octet 36 


Octet 37 


16-bit unsigned 
integer 


n/a 


Sequence number field. Indicates the index 
of the sent GeoUnicast packet (clause 7.3) 
and used to detect duplicate 
GeoNetworking packets (annex A). 


3 


LT 


Octet 38 


Octet 38 


8-bit unsigned 
integer 


n/a 


Lifetime field. Indicates the maximum 
tolerable time a packet can be buffered 
until it reaches its destination. 
Bit to 5: LT sub-field IVIultiplier. 
Bit 6 to 7: LT sub-field Base. 
Encoded as shown in clause 8.5.7. 


4 


Reserved 


Octet 39 


Octet 39 


8-bit unsigned 
integer 


n/a 


Reserved for media-dependent 
functionality. 


5 


SOPV 


Octet 40 


Octet 67 


Long position 
vector 


n/a 


Long position vector of the source as 

specified in clause 8.4.2 (Long Position 

Vector). 

Length: 28 octets. 


6 


DEPV 


Octet 68 


Octet 87 


Short position 
vector 


n/a 


Short position vector of the destination. It 
shall consist of the fields as specified in 
clause 8.4.3 (Short Position Vector). 
Length: 20 octets. 



8.6.3 TSB packet header 



8.6.3.1 Composition of the TSB packet header 

The TSB header shall be comprised of the Common Header and the Extended Header as shown in figure 12. 
NOTE: The Extended Header comprises all fields except the Common Header. 
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Figure 12: Packer header format: TSB 
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8.6.3.2 Fields of the TSB packet header 

The TSB packet header shall consist of the fields as specified in table 1 1 . 

Table 1 1 : Fields of the TSB packet header 



Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


Common 
Header 


Octet 


Octet 35 


Common 
Header 


n/a 


Common header as specified in clause 8.5. 


2 


SN 


Octet 36 


Octet 37 


16-bit unsigned 
integer 


n/a 


Sequence number field. Indicates the index of 
the sent GeoUnicast packet (clause 7.3) and 
used to detect duplicate GeoNetworking 
packets (annex A). 


3 


LT 


Octet 38 


Octet 38 


8-bit unsigned 
integer 


[s] 


Lifetime field. Indicates the maximum tolerable 
time a packet can be buffered until it reaches 
its destination. 
Encoded as shown in clause 8.5.7. 


4 


Reserved 


Octet 39 


Octet 39 


8-bit unsigned 
integer 


n/a 


Reserved for media-dependent functionality. 


5 


SOPV 


Octet 40 


Octet 67 


Long Position 
Vector 


n/a 


Long position vector of the source as specified 
in clause 8.4.2 (Long Position Vector). 
Length: 28 octets. 



8.6.4 SHB packet header 



8.6.4.1 Composition of the SHB packet header 

The SHB header shall consist of a Common Header only. It has no Extended Header (see figure 13). 

12 3 

01234567012345670123456701234567 

Common Header 

I 

Figure 13: Packer header format: SHB 

8.6.4.2 Fields of the SHB packet header 

The SHB packet header shall consist of the fields as specified in table 12. 

Table 12: Fields of the SHB packet header 



Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


Common 
Header 


1 


36 


Common 
Header 


n/a 


Common header as specified in clause 8.5. 



8.6.5 GeoBroadcast/GeoAnycast packet header 



8.6.5.1 



Composition of the GeoBroadcast/GeoAnycast packet header 



The GeoBroadcast and GeoAnycast packets shall have the same header structure. They are distinguished by the HT 
field in the Common Header. 

The header shall be comprised of the Common Header and the Extended Header as shown in figure 14. 

NOTE: The Extended Header comprises all fields except the Common Header. 
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Figure 14: Packer header format: GeoBroadcast/GeoAnycast 

8.6.5.2 Fields of the GeoBroadcast/GeoAnycast packet header 

The GeoBroadcast/GeoAnycast packet header shall consist of the fields as specified in table 13. 

Table 13: Fields of the GeoBroadcast/GeoAnycast packet header 



Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


Common 
Header 


Octet 


Octet 35 


Common 
Header 


n/a 


Common header as specified in clause 8.5. 


2 


SN 


Octet 36 


Octet 37 


16-bit 

unsigned 

integer 


n/a 


Sequence number field. Indicates the index 
of the sent GeoUnicast packet (clause 7.3) 
and used to detect duplicate GeoNetworking 
packets (annex A). 


3 


LT 


Octet 38 


Octet 38 


8-bit unsigned 
integer 


n/a 


Lifetime field. Indicates the maximum 
tolerable time a packet can be buffered until 
it reaches its destination. 
Encoded as shown in clause 8.5.7. 


4 


Reserved 


Octet 39 


Octet 39 


8-bit unsigned 
integer 


n/a 


Reserved for media-dependent functionality. 


5 


SOPV 


Octet 40 


Octet 67 


Long position 
vector 


n/a 


Long position vector of the source as 

specified in clause 8.4.2 (Long Position 

Vector). 

Length: 28 octets. 


6 


GeoAreaPos 
Latitude 


Octet 68 


Octet 71 


32-bit signed 
integer 


[1/10 micro- 
degree] 


WGS-84 latitude for the center position of 
the geometric shape as defined in [7] in 
1/10 micro degree. 


7 


GeoAreaPos 
Longitude 


Octet 72 


Octet 75 


32-bit signed 
integer 


[1/10 micro- 
degree] 


WGS-84 longitude for the center position of 
the geometric shape as defined in [7] in 
1/10 micro degree. 


8 


Distance a 


Octet 76 


Octet 77 


16-bit 

unsigned 

integer 


[m] 


Distance a of the geometric shape as 
defined in [7] in meters. 


9 


Distance b 


Octet 78 


Octet 79 


16-bit 

unsigned 

integer 


[m] 


Distance b of the geometric shape as 
defined in [7] in meters. 


10 


Angle 


Octet 80 


Octet 81 


16-bit 

unsigned 

integer 


["] 


Angle of the geometric shape as defined in 
[7] in degrees from North. 


11 


Reserved 


Octet 82 


Octet 83 


16-bit 

unsigned 

integer 


n/a 


Unused. 



In case of a circular area (GeoNetworking packet sub-type HST= 0), the fields shall be set to the following values: 

• Distance a is set to the radius r. 

• Distance b is set to 0. 

• Angle is set to 0. 
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8.6.6 BEACON packet header 



8.6.6.1 Composition of the BEACON packet header 

A BEACON packet shall consist of a Common Header only. It has no Extended Header (see figure 15). 

12 3 

01 23456701 23456701 23456701 234567 

Common Header 

I 

Figure 15: Packer header format: BEACON 

8.6.6.2 Fields of the BEACON packet header 

The BEACON shall consist of the fields of a Common Header only as specified in table 14. 

Table 14: Fields of the BEACON packet header 



Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


Common 
Header 


Octet 


Octet 35 


Common 
Header 


n/a 


Common header as specified in clause 8.5. 



8.6.7 LS Request header 



8.6.7.1 



Composition of the LS Request header 



The LS Request packet header shall be comprised of the Common Header and the Extended Header as shown in 
figure 16. 

NOTE: The Extended Header comprises all fields except the Common Header. 
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Figure 16: Packer header format: LS Request 
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8.6.7.2 Fields of the LS Request packet header 

The LS Request packet header shall carry the fields as specified in table 15. 

Table 15: Fields of the LS Request packet header 



Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


Common 
Header 


Octet 


Octet 35 


Common Header 


n/a 


Common header as specified in clause 8.5. 


2 


SN 


Octet 36 


Octet 37 


16-bit unsigned 
integer 


n/a 


Sequence number field. Indicates the index of 
the sent GeoUnicast packet (clause 7.3) and 
used to detect duplicate GeoNetworking 
packets (annex A). 


3 


LT 


Octet 38 


Octet 38 


8-bit unsigned 
integer 


n/a 


Lifetime field. Indicates the maximum tolerable 
time a packet can be buffered until it reaches 
its destination. 
Encoded as shown in clause 8.5.7. 


4 


Reserved 


Octet 39 


Octet 39 


8-bit unsigned 
integer 


n/a 


Reserved for media-dependent functionality. 


5 


SOPV 


Octet 40 


Octet 67 


Long position 
vector 


n/a 


Long position vector of the source as specified 
in clause 8.4.2 (Long Position Vector). 
Length: 28 octets. 


6 


Request 
GN_ADDR 


Octet 68 


Octet 75 


64-bit address 


n/a 


The GN_ADDR address for the GeoAdhoc 
router entity for which the location is being 
requested. 



8.6.8 LS Reply packet header 



8.6.8.1 



Composition of the LS Reply packet header 



The LS Reply packet header shall be comprised of the Common Header and the Extended Header as shown in 
figure 17. 

NOTE: The Extended Header comprises all fields except the Common Header. 
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Figure 17: Packer header format: LS Reply 
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8.6.8.2 Fields of the LS Reply packet header 

The LS Reply packet header shall carry the fields as specified in table 16. 

Table 16: Fields of the LS Reply packet header 
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Field 

# 


Field name 


Octet/bit position 


Type 


Unit 


Description 


First 


Last 


1 


Common 
Header 


Octet 


Octet 35 


Common 
Header 


n/a 


Common header as specified in clause 8.5. 


2 


SN 


Octet 36 


Octet 37 


16-bit 

unsigned 

integer 


n/a 


Sequence number field. Indicates the index of 
the sent GeoUnicast packet (clause 7.3) and 
used to detect duplicate GeoNetworking 
packets (annex A). 


3 


LT 


Octet 38 


Octet 38 


8-bit unsigned 
integer 


n/a 


Lifetime field. Indicates the maximum tolerable 
time a packet can be buffered until it reaches 
its destination. 
Encoded as shown in clause 8.5.7. 


4 


Reserved 


Octet 39 


Octet 39 


8-bit unsigned 
integer 


n/a 


Reserved for media-dependent functionality. 


5 


SOPV 


Octet 40 


Octet 67 


Long position 
vector 


n/a 


Long position vector of the source, which 
represents the Request GN_ADDR in the 
corresponding LS Request, as specified in 
clause 8.4.2. (Long Position Vector). 
Length: 28 octets. 


6 


DEPV 


Octet 68 


Octet 87 


Short position 
vector 


n/a 


Short position vector of the destination. It shall 
carry the fields as specified in clause 8.4.3 
(Short Position Vector). 
Length: 20 octets. 



Protocol operation 



9.1 General 

This clause specifies the media-independent operations of the GeoNetworking protocol. 
The operations include: 

• Network management: 

Address configuration (clause 9.2.1). 

Local position vector and time update (clause 9.2.2). 

Beaconing (clause 9.2.3). 

Location service (clause 9.2.4). 

• Packet handling: 

GeoUnicast (clause 9.3.4). 
TSB (clause 9.3.5). 
SHE (clause 9.3.6). 
GeoBroadcast (clause 9.3.7). 
GeoAnycast (clause 9.3.8). 
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9.2 Network management 
9.2.1 Address configuration 

9.2.1.1 General 

At start-up, a GeoAdhoc router shall have a self-assigned initial GeoNetworking address with the format specified in 
clause 6. GeoNetworking defines two methods for the configuration of the local GN_ADDR 

• Auto-address configuration (clause 9.2.1.2). 

• Managed address configuration(clause 9.2.1.3). 

The method is defined in the MIB attribute itsGnLocalAddrConfMethod. 

In the managed address configuration, the initial GeoNetworking address (clause 9.2.1.3.1) of the GeoAdhoc router can 
be updated (clause 9.2.1.3.2). 

Operations for duplicate address detection are specified in clause 9.2.1.4. 

9.2.1 .2 Auto-address configuration 

The auto-address configuration method shall be used if the MIB attribute ItsGnLocalAddrConfMethod is set to 
AUTO (0). 

At start-up, the GeoAdhoc router shall assign its local GN_ADDR from the MIB attribute itsGnLocalGnAddr. 

NOTE: The setting of the MIB attribute itsGnLocalGnAddr is implementation dependent. One example 
implementation is the usage of randomly-generated addresses. 

The local GN_ADDR shall not be changed unless the MIB attribute ItsGnLocalAddrConfMethod is set to 
MANAGED (1). 

9.2.1 .3 Managed address configuration 

The managed address configuration method shall be used if the MIB attribute ItsGnLocalAddrConfMethod is set to 
MANAGED (1). 

With managed address configuration, the ITS Network and Transport Layer Management layer is responsible for 
providing the GeoAdhoc router a GN_ADDR. 

9.2.1 .3.1 Initial address configuration 

At startup, the GeoAdhoc router shall request a GN_ADDR from the ITS Network and Transport Layer Management 
entity using the GN-MGMT. request primitive (clause 1.2). The ITS Network and Transport Layer Management entity is 
responsible for generating the appropriate GeoNetworking address using the GN-MGMT.response primitive (clause 1.3). 

9.2.1.3.2 Address update 

The update of the local GN_ADDR can be triggered by the GeoAdhoc router or the ITS Network and Transport Layer 
Management entity. 

If the update is triggered by the GeoAdhoc router, the GeoAdhoc router shall use the GN-MGMT. request primitive 
(clause 1.2). The ITS Network and Transport Layer Management entity is responsible for generating the appropriate 
GeoNetworking address using the GN-MGMT.response primitive (clause 1.3). 

If the update is triggered by the ITS Network and Transport Layer Management entity, the ITS Network and Transport 
Layer Management entity sends an unsolicited GN-MGMT.response to the GeoAdhoc router. Upon reception of the 
GN-MGMT.response, the GeoAdhoc router shall update its local GN_ADDR. 
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NOTE 1 : For privacy reasons, the GN_ADDR can be derived from the station's short-term identity or pseudonym. 
The frequency of update and the algorithm of generating pseudonyms are beyond the scope of the present 
document. 

NOTE 2; From communication point of view, a frequent update of the GN_ADDR can impair the performance of 
the GeoNetworking protocol. 

9.2.1 .4 Duplicate address detection 

The configuration of the GeoNetworking address does not guarantee its uniqueness. In order to achieve uniqueness, a 
GeoAdhoc router shall execute the following operations for duplicate address detection: 

• Upon reception of a GeoNetworking packet, the GeoAdhoc router compares its local GN_ADDR and the 

GN_ADDR of the SE and SO carried in the GeoNetworking packet header. The comparison is done based on 
the last field of the GN_ADDR (MID) which corresponds to the 48-bit MAC address. 



• 



If a conflict is detected, the GeoNetworking protocol entity shall request a new GeoNetworking address from 
the ITS Network and Transport Layer Management entity using a GN-MGMT. request primitive (clause 1.2) 
indicating Duplicate address as the Request cause. 

9.2.2 Local position vector and time update 

9.2.2.1 Overview 

Local position and time are set by the Network and Transport Layer Management entity via the GN_MGT interface 
(clause 1.3). 

9.2.2.2 Local Position Vector update 

For position update, the ITS Network and Transport Layer Management entity shall send an unsolicited 
GN-MGMT. response with the Local position vector parameter (clause 1.3) to the GeoAdhoc router. Upon reception of 
the GN-MGMT.response with the Local position vector parameter, the GeoAdhoc router shall update its Local Position 
Vector (LPV) (clause 7.2). 

As specified in clause 7.2.3, the LPV shall be updated with a minimum frequency of the MIB attribute 
itsGnMinimumUpdateFrequencyLPV. 

9.2.2.3 Time update 

For time update, the ITS Network and Transport Layer Management entity shall send an unsolicited 
GN-MGMT.response with the Time parameter (clause 1.3) to the GeoAdhoc router. Upon reception of the 
GN-MGMT.response with the Time parameter, the GeoAdhoc router shall set its local system time. 

NOTE: Details of the system time management and usage are implementation specific. 

9.2.3 Beaconing 
9.2.3.1 Overview 

Beaconing is used to periodically advertise a GeoAdhoc router's position vector to its neighbours. 

A BEACON packet shall be sent periodically unless the GeoAdhoc router sends another GeoNetworking packet that 
carries the GeoAdhoc router's LPV. 

NOTE: Typically, this is implemented by a timer that is reset upon transmission of any GeoNetworking packet. 
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9.2.3.2 Source operations 

At start-up, a GeoAdhoc router shall execute the following operations: 

1) create a GN-PDU with a BEACON packet header (clause 8.6.6) and the field settings as specified in table 17; 

2) execute media-dependent procedures: if the Communication profile parameter of the GN-DATA.request 
primitive is set to: 

a) UNSPECIFIED then omit this operation; 

b) is set to ITS-G5A then execute the operations as specified in [i.2]; 

3) pass the GN-PDU to the LL protocol entity via the IN interface and set the destination address to the Broadcast 
address of the LL entity; 

Table 17: Field settings for the Common Header in BEACON packets 



Field name 


Field setting 


Description 


Version 


MIB attribute itsGnProtocolVersion 


Version of the GeoNetworking protocol. 


NH 


(ANY) 


Next header (table 5 in clause 8.5.3). 


HT 


1 (BEACON) 


Header type (table 6 in clause 8.5.4). 


HST 


(UNSPECIFIED) 


Header sub-type (specified in table 6 in 
clause 8.5.4). 


Reserved 





Unused fields. 


Flags 


Bit to 5: 

Bit 6: itsGnStationType (IVIIB attribute) 

Bit 7: 


Only Bit 6 used. Other fields reserved for future 
use. 


PL 





Pay load length (packet does not carry payload). 


TC 


Bit 0: (Reserved) 
Bit 1 to 3: IVIIB attribute 
itsGnTrafficClassRelevance (Relevance) 
Bit 4 to 5: MIB attribute 
itsGnTrafficClassReliability (Reliability) 
Bit 6 to 7: MIB attribute 
itsGnTrafficClassLatency (Latency) 


Traffic class as specified in clauses 8.5.5 
and 8.5.6. 


HL 


Set to 1 


Hop limit. 


SEPV 


Actual values of the LPV (clause 7.2). 


PV of the local GeoAdhoc router (sender of the 
BEACON packet). 



4) initialize the timer for the periodic transmission of beacons Teeacon with a timeout set to 

(itsGnBeaconServiceRetransmitTimer + RAND[0,itsGnBeaconServiceMaxJitter]), whereas 
itsGnBeaconServiceRetransmitTimer and itsGnBeaconServiceMaxJitter represent MIB attribute values. 

NOTE: The RAND function introduces a random component for the timer to avoid synchronization issues among 
GeoAdhoc routers. 

If the timer TBeacon expires, the source shall execute the following operations: 

1) create a GN-PDU with a BEACON packet header (clause 8.6.6) and the field settings as specified in table 17; 

2) execute media-dependent procedures: if the Communication profile parameter of the GN-DATA.request 
primitive is set to: 

a) UNSPECIFIED then omit this operation; 

b) is set to ITS-G5A then execute the operations as specified in [i.2]; 

3) pass the GN-PDU to the LL protocol entity via the IN interface and set the destination address to the Broadcast 
address of the LL entity; 

4) set the timer TBeacon to a timeout set to (itsGnBeaconServiceRetransmitTimer + 
RAND[0,itsGnBeaconServiceMaxJitter)) 

The GeoAdhoc router shall reset the timer Teeacon for every sent GeoNetworking packet. 
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9.2.3.3 Receiver operations 

If a GeoAdhoc router receives a BEACON packet, it shall execute the following operation: 
1) Common Header processing (clause 9.3.3). 

9.2.4 Location service 



9.2.4.1 



General 



The location service is used if a GeoAdhoc router needs to determine the position of another GeoAdhoc router. This is 
the case if a GeoAdhoc router is in the process to send a T/GN6-SDU as a GeoUnicast packet to another GeoAdhoc 
router, i.e. from the source to the destination, and does not have the position information for the destination in its LocT. 

The execution of a location service is fully transparent to protocol entities of higher layers. 

The location service function resides on top of the forwarding functions and can therefore use any forwarding type. 

The location service is based on the exchange of control packets between GeoAdhoc routers (figure 18). The querying 
GeoAdhoc router (source) issues a LS Request packet with the GN_ADDR of the sought GeoAdhoc router 
(destination). The LS Request packet is forwarded by intermediate GeoAdhoc routers (forwarders) until it reaches the 
destination. The destination replies with a LS Reply packet. 



Source 



Forwarder 1 



Forwarder 2 



Destination 



LS REQUEST 



LS REPLY 



LS REQUEST 



LS REPLY 



LS REQUEST 



LS REPLY 



Figure 18: Message sequence chart for the location service (example scenario with two forwarders) 
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Table 18: Field settings for the Common Header in LS Request and LS Reply packets 



Field name 


Field setting 


Description 


Version 


MIB attribute itsGnProtocolVersion 


Version of the GeoNetworking protocol. 


NH 





Next header (table 5 in clause 8.5.3). 


HT 


6(LS) 


Header type (table 6 in clause 8.5.4). 


HST 


(LS REQUEST) 

1 (LS REPLY) 


Header sub-type (specified in table 6 in 
clause 8.5.4). 


Reserved 





Unused fields. 


Flags 


Bit to 5: 

Bit 6: itsGnStationType (MIB attribute) 

Bit 7: 


Only Bit 6 used. Other fields reserved for future 
use. 


PL 





Payload length (packet does not carry payload). 


TC 


Bit 0: (Reserved) 
Bit 1 to 3: MIB attribute 
itsGnTrafficGlassRelevance (Relevance) 
Bit 4 to 5: MIB attribute 
ItsGnTrafficClassReliability (Reliability) 
Bit 6 to 7: MIB attribute 
ItsGnTrafficClassLatency (Latency) 


Traffic class as specified in clauses 8.5.5 
and 8.5.6. 


HL 


MIB attribute ItsGnDefaultHopLlmit 


Hop limit. 


SEPV 


Actual values of the LPV (clause 7.2). 


PV of the local GeoAdhoc router (sender of the LS 
Request and LS Reply packet). 



9.2.4.2 Source operations 

9.2.4.2.1 Overview 

Three cases are distinguished for the source operations: 

• Source operation for initial LS Request (clause 9.2.4.2.2). 

• Source operation for LS Request re-transmission (clause 9.2.4.2.3). 

• Source operation for LS Reply (clause 9.2.4.2.4). 



9.2.4.2.2 



Source operation for initial LS Request 



When a source has a T/GN6-SDU to send and has no position vector information for the destination address, the source 
shall invoke the location service and shall execute the following operations: 

1) check whether a LS for the sought GN_ADDR is in progress, i.e. the flag LS_pending is set TRUE: 

a) if LS_pending is TRUE for the sought GN_ADDR, the packet shall be buffered in the LS packet buffer 
(clause 7.4) and the execution of the next steps shall be omitted; 

2) issue a LS Request packet with a format as specified in clause 8.6.7 as a TSB packet: 

a) set the fields of the Common Header to the values specified in table 18; 

b) set the fields of the LS Request Extended Header to the values specified in table 19. 
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Table 19: Field settings for the LS Request Extended Header 



Field name 


Field setting 


Description 


SN 


Actual value of the local sequence number 
as specified in clause 7.3. 


Sequence number of the packet. 


LT 


Value of Maximum lifetime parameter from 
GN-DATA.request primitive. 


Lifetime. 


SOPV 


Actual values of the LPV as specified in 
clause 7.2. 


Position vector of the local GeoAdhoc router 
(source of the GeoNetworking packet). 


Request GN_ADDR 


GN_ADDR from GN-DATA.request 
parameter Destination (annex H). 


GeoNetworking address of the sought GeoAdhoc 
router. 



3) start a timer Tls, gn_addr with a timeout set to the value of the MIB attribute 
itsGnLocationServiceRetransmitTimer; 

4) initialize the LS retransmit counter for the GeoAdhoc router GN_ADDR RTCls. gn_addr to 0; 

5) add a LocTE for the sought GN_ADDR in its LocT and sets the flag LS_pending to TRUE. 

9.2.4.2.3 Source operation for LS Request re-transmission 

If the timer Tls, gn_addr for the GN_ADDR expires, the source shall execute the following operation: 

1) check the retransmit counter RTCls, gn_addr; 

2) if the retransmit counter is less than the maximum number of LS retransmissions set by the MIB attribute 
itsGnLocationServiceMaxRetrans, i.e. RTCls, gn_addr < itsGnLocationServiceMaxRetrans the GeoAdhoc 
router shall: 

a) re- issue a LS Request packet with the format as specified in clause 8.6.7 as a TSB packet; 

b) restart the timer Tls. gn_addr with a timeout set to of itsGnLocationServiceRetransmitTimer; and 

c) increment the retransmit counter RTCls, gn_addr; 

3) if the retransmit counter is greater equal than the maximum number of LS retransmissions set by the MIB 
attribute itsGnLocationServiceMaxRetrans, i.e. RTCls. gn_addr > itsGnLocationServiceMaxRetrans the 
GeoAdhoc router shall: 

a) flush the LS packet buffer (clause 7.4) for the sought GN_ADDR and discard the stored packets; 

b) remove the LocTE for the sought GN_ADDR. 

9.2.4.2.4 Source operation for LS Reply 

If the source receives a LS Reply packet for the sought GN_ADDR, the source shall execute the following operations: 

1) Common Header processing (clause 9.3.3); 

2) execute duplicate packet detection (annex A); if the LS Reply packet is a duplicate, discard the packet and 
omit the execution of further steps; 

3) update the SO PVloct with the SO PV of the received LS Reply Extended Header using the algorithm specified 
in clause B.2; 

4) set the SO IS_NEIGHBOUR flag to FALSE, if the SO GN_ADDR does not equal the SE GN_ADDR; 

5) flush packet buffers (SO LS packet buffer, SO UC forwarding packet buffer): 
a) if SO LS_pending is TRUE: 

i. flush the SO LS packet buffer (clause 7.4); 
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ii. forward the stored packets; 

iii. set SO LS_pending to false; 

b) if the UC forwarding packet buffer (clause 7.5) for SO is not empty, flush the UC forwarding buffer and 
forward the stored packets; 

6) flush the LS packet buffer (clause 7.4) for the sought GN_ADDR and forward the stored packets; 

7) set the flag LS_pending for the sought GN_ADDR to false; 

8) stop the timer Tls, gn_addr; 

9) reset the re-transmit counter RTCls, gn_addr- 

9.2.4.3 Forwarder operations 

If a GeoAdhoc router receives a LS Request packet and the Request GN_ADDR field in the LS Request header does not 
match its GN_ADDR, the GeoAdhoc router shall handle the packet according to the packet handling procedure for TSB 
(clause 9.3.5.3), except step 7 for passing the payload of the GN-PDU to the upper protocol entity. 

If a GeoAdhoc router receives a LS Reply packet and the GN_ADDR in the DE PV of the LS Reply packet does not 
match its GN_ADDR, the GeoAdhoc router shall handle the packet according to the packet handling operations for 
GeoUnicast (clause 9.3.4). 

NOTE: The Common Header processing and duplicate packet detection is part of the GeoUnicast and TSB packet 
handling procedure, respectively. 

9.2.4.4 Destination operations 

On reception of a LS Request packet, the GeoAdhoc router shall check the Request GN_ADDR field. If this MID field 
matches the MID field of its GN_ADDR, the GeoAdhoc router shall execute the following operations: 

1) Common Header processing (clause 9.3.3); 

2) execute duplicate packet detection (annex A); if the LS Request packet is a duplicate, discard the packet and 
omit the execution of further steps; 

3) update the SO PVloct with the SO PV fields of the LS Request Extended Header using the algorithm specified 
in clause B.2; 

4) set the SO IS_NEIGHBOUR flag to FALSE if SO GN_ADDR does not equal the SE GN_ADDR; 

5) issue a LS Reply packet as a GeoUnicast packet (clause 8.6.2) and forward the packet according to the 
forwarding procedure for GeoUnicast (clause 9.3.4). 

9.3 Packet handling 
9.3.1 Overview 

This clause defines the behaviour of the protocol in the source, forwarder and destination. Packet handling includes the 
procedures to determine the destination (GeoAdhoc router, geographical area) of the T/GN6-SDU, execute functions 
that are specific to the packet type, and pass the GN-PDU to the LL protocol entity via the IN interface. 

The following packet handling types are defined: 

• GeoUnicast packet handling (clause 9.3.4); 

• TSB packet handling (clause 9.3.5); 

• SHB packet handling (clause 9.3.6); 

• GeoBroadcast packet handling (clause 9.3.7); and 
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• GeoAnycast packet handling (clause 9.3.8). 

The packet handling is further specified in the following clauses. 

NOTE: The current version of the present document does not make use of all fields carried in the GeoNetworking 
packet header. In particular, the altitude, speed, heading and accuracy fields are not used. 

9.3.2 Common Header field settings 

For all GeoNetworking packets of type GeoUnicast, SHB, TSB, GeoBroadcast and GeoAnycast, the fields of the 
Common Header shall be set as specified in table 20. 

Table 20: Field settings for the Common Header 



Field name 


Field setting 


Description 


Version 


IVIIB attribute itsGnProtocolVersion 


Version of the GeoNetworking protocol. 


NH 


1 (BTP) if GA/-D/A7/\.requesf parameter 
Upper protocol entity is BTP 

2 (IPv6) if G/V-D/\ 77\.reqt;esf parameter 
Upper protocol enWXy is IPv6 


Next header (table 5 in clause 8.5.3) 


HT 


2 (GEOUNICAST) if GN-DATA.request 
parameter Packet transport type is 
GeoUnicast 

3 (GEOANYGAST) if GN-DATA.request 
parameter Packet transport type is 
GeoAnycast 

4 (GEOBROADGAST) if GN-DATA.request 
parameter Packet transport type is 
GeoBroadcast 

5 (TSB) if GA/-D/A7/\.requesf parameter 
Packet transport type is TSB 

5 (TSB) if GA/-D/A7/\.requesf parameter 
Packet transport type is SHB 


Header type (table 6 in clause 8.5.4) 


HST 


As specified in table 6 in clause 8.5.4 


Header sub-type 


Reserved 





Unused fields. 


Flags 


Bit to 5: 

Bit 6: IVIIB attribute itsGnStationType 

Bit 7: 


Only bit 6 used. Other fields reserved for future 
use. 


PL 


Size of T/GN6-SDU defined in 
GN-DATA.request 


Payload length in bytes 


TC 


Traffic class defmed in GN-DATA.request 
primitive parameter Traffic class 


Traffic class, encoded as specified in clause 8.5.5 


HL 


Source: 

• 1 if GA/-D/A7/A.requesf parameter Pac/cef 

transport type is SHB 

• MIB attribute itsGnOefaultHopLimit 

if GA/-D/A7/\.requesf parameter Packet 
transport type is GeoUnicast, 
GeoAnycast, GeoBroadcast or TSB 

Forwarder: 

Decrement HL by one 


Hop limit 


SEPV 


Actual values of the LPV as specified in 
clause 7.2 


PV of the local GeoAdhoc router (sender of the 
GeoNetworking packet) 



NOTE: TSB and SHB carry the same value in the HT field (equals 5), but have a different value in the HST field, 
i.e. HST = for SHB and HST = 1 for TSB (table 6 in clause 8.5.4). 
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9.3.3 Common Header processmg 



When a GeoAdhoc router (forwarder, receiver, destination) processes a Common Header upon reception of a 
GeoNetworking packet, the GeoAdhoc router shall execute the following operations: 

1) update the PV in the SE LocTE with the SE PV fields of the Common Header (clause B.2); 

2) set the IS_NEIGHBOUR flag of the SE LocTE to TRUE; 

3) flush packet buffers (SE LS packet buffer, SE UC forwarding packet buffer, BC forwarding packet buffer): 

a) if SE LS_pending is TRUE: 

i. flush the SE LS packet buffer (clause 7.4); 
ii. forward the stored packets; 
iii. set SE LS_pending to false; 

b) if the UC forwarding packet buffer (clause 7.5) for SE is not empty, flush the UC forwarding buffer and 
forward the stored packets; 

c) if the BC forwarding packet buffer (clause 7.5) is not empty, flush the BC forwarding buffer and forward 
packets; 

4) check the NH field of the Common Header: 

a) if NH = (ANY) discard the packet and omit the execution of further steps; 

NOTE: NH = (ANY) is used by network management packets, i.e. beaconing (clause 9.2.3) and location 
service (clause 9.2.4). 

5) check the HT field of the Common Header: 

a) if HT = (ANY) discard the packet and omit the execution of further steps. 

9.3.4 GeoUnicast packet handling 

9.3.4.1 General 

This clause specifies the operations of a GeoAdhoc router to handle a GeoUnicast packet. The following clauses define 
the operations of the source, forwarder and destination. 

GeoUnicast forwarding applies the algorithm selected by the setting of the value in the MIB attribute 
itsGnGeoUnicastForwardingAlgorithm and specified in annex C. 

9.3.4.2 Source operations 

On reception of a GN-DATA. request primitive with a Packet transport type parameter set to GeoUnicast, the source 
shall execute the following operations: 

1) check whether it has a valid position vector for DE in its LocT: 

a) If no valid position vector information is available, the source shall invoke the location service as 

specified in clause 9.2.4 and omit the execution of further steps. Otherwise, the source shall proceed with 
step 2; 

2) determine the link-layer address LL_ADDR_NH of the next hop (annex C): 

a) if the MIB attribute ItsGnGeoUnicastForwardingAlgorithm is set to (UNSPECIFIED), 
execute the GF algorithm as specified in clause C.2; 

b) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 1 (GREEDY), execute the GF 
algorithm as specified in clause C.2; 
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c) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 2 (CBF), execute the CBF 
algorithm as specified in clause C.3; 

NOTE: The CBF algorithm returns the broadcast LL or, in case of no neighbours, (see clause C.3). 

3) create a GN-PDU with the T/GN6-SDU as payload and a GeoUnicast packet header (clause 8.6.2): 

a) set the fields of the Common Header (clause 9.3.2); 

b) set the fields of the GeoUnicast Extended Header (table 21). 

Table 21 : Field settings for the GeoUnicast Extended Header 



Field name 


Field setting 


Description 


SN 


Actual value of the local sequence number 
(clause 7.3). 


Sequence number of the packet 


LT 


Value of Maximum lifetime parameter from 
the GA/-D/A7/\.requesf primitive. 


Lifetime 


SOPV 


Actual values of the LPV (clause 7.2). 


Position vector of the local GeoAdhoc router 
(source of the GeoNetworking packet) 


DEPV 


Actual values of the LocTE for the 
destination. 


Position vector of the destination 



4) if LL_ADDR_NH = 0, then buffer the GeoUnicast packet in the UC forwarding packet buffer and omit the 
execution of further steps; 

5) if the optional Repetition interval parameter in the GN-DATA.request parameter is set: 

a) save the GeoUnicast packet; 

b) retransmit the packet with period as specified in Repetition interval until the maximum lifetime of the 
packet is expired; 

NOTE 2: The lifetime of the packet is specified in the Maximum lifetime parameter of the GN-DATA.request 
primitive. 

NOTE 3: For every retransmission, the operations need to be re-executed. 

6) execute media-dependent procedures: if the Communication profile parameter of the GN-DATA.request 
primitive is set to: 

a) UNSPECIFIED then omit this operation; 

b) ITS-G5A then execute the operations as specified in [i. 2]; 

7) pass the GN-PDU to the LL protocol entity via the IN interface and set the destination address to the LL 
address of the next hop LL_ADDR_NH. 



9.3.4.3 



Forwarder operations 



On reception of a GeoUnicast packet, the GeoAdhoc router shall check the GN_ADDR field in the DE PV of the 
GeoUnicast packet header. If this address does not match its GN_ADDR, the GeoAdhoc router shall execute the 
following operations: 

1) Common Header processing (clause 9.3.3); 

2) execute duplicate packet detection (annex A); if the GeoUnicast packet is a duplicate, discard the packet and 
omit the execution of further steps; 

3) update the PV(SO) in the LocT with the SO PV fields of the GeoUnicast Extended Header (clause B.2); 

4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal SE GN_ADDR; 
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5) flush packet buffers (SO LS packet buffer, SO UC forwarding packet buffer): 

a) if LS_pending(SO) is TRUE: 

i. flush the SO LS packet buffer (clause 7.4); 
ii. forward the stored packets; 
iii. set LS_pending(SO) to false; 

b) if the UC forwarding packet buffer (clause 7.5) for SO is not empty, flush the UC forwarding buffer and 
forward the stored packets; 

6) update the DE PV(DE) in the LocT with DE PV fields in the GeoUnicast Extended Header (clause B.2); 

7) update the fields of the Common Header, i.e.: 

the HL field with the decremented HL value; 
the SE PV fields with the LPV (clause 7.2); 

8) update the DE PV fields with the PV(DE) in the LocT (clause B.3); 

9) decrement the value of the HL field by one; if HL is decremented to zero, discard the GN-PDU and omit the 
execution of further steps; 

10) determine the link-layer address LL_ADDR_NH of the next hop (annex C): 

a) if the MIB attribute itsGnOeoUnicastForwardingAlgorithm is set to (UNSPECIFIED), execute the GF 
algorithm as specified in clause C.2; 

b) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 1 (GREEDY), execute the GF 
algorithm as specified in clause C.2; 

c) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 2 (CBF), execute the CBF 
algorithm as specified in clause C.3; 

11) if LL_ADDR_NH = 0, then buffer the GeoUnicast packet in the UC forwarding packet buffer and omit the 
execution of further steps; 

12) execute media-dependent procedures: if the Communication profile parameter of the GN-DATA. request 
primitive is set to: 

a) UNSPECIFIED then omit this operation; 

b) ITS-G5Athen execute the operations as specified in [i. 2]; 

13) pass the GN-PDU to the LL protocol entity via the IN interface and set the destination address to the LL 
address of the next hop LL_ADDR_NH. 

9.3.4.4 Destination operations 

On reception of a GeoUnicast packet, the GeoAdhoc router shall check the GN_ADDR field in the DE PV of the 
GeoUnicast packet header. If this address matches its GN_ADDR, the GeoAdhoc router shall execute the following 
operations: 

1) Common //eofier processing (clause 9.3.3); 

2) execute duplicate packet detection (annex A); if the GeoUnicast packet is a duplicate, discard the packet and 
omit the execution of further steps; 

3) update the PV(SO) in the LocT with the SO PV fields of the GeoUnicast Extended Header (clause B.2); 

4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal the SE GN_ADDR; 
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5) flush packet buffers (SO LS packet buffer, SO UC forwarding packet buffer): 

a) if LS_pending(SO) is TRUE: 

i. flush the SO LS packet buffer (clause 7.4); 
ii. forward the stored packets; 
iii. set LS_pending(SO) to false; 

b) if the UC forwarding packet buffer (clause 7.5) for SO is not empty, flush the UC forwarding buffer and 
forward the stored packets; 

6) pass the payload of the GN-PDU to the upper protocol entity by means of a GN-DATA. indication primitive 
with the parameter settings in table 22. 

Table 22: Parameter settings in the GN-DATA.indication primitive 
to indicate a received GeoUnicast pacltet 



Parameter name 


Parameter setting 


Upper protocol entity 


BTP if NH = 1 (BTP-A) 

BTP if NH = 2 (BTP-B) 

IPv6 if NH = 3 (IPv6) 

(NH encoding see table 5 in clause 8.5.3) 


Packet transport type 


GeoUnicast 


Destination 


DE GN ADDR 


Source position vector 


Values of SO P\/from Extended Header 


Traffic class 


Value of 7C field from GeoUnicast Common Header 


Remaining packet lifetime 


Value of /.7from GeoUnicast Common Header 


Length 


Length of the GN-PDU payload 


Data 


GN-PDU payload 



9.3.5 TSB packet handling 



9.3.5.1 



General 



This clause specifies the operations of a GeoAdhoc router to handle a TSB packet. The following clauses define the 
operations of the source and forwarder/receiver. 

NOTE: In TSB, a forwarder is also always a receiver. Therefore, the roles are not distinguished. 

9.3.5.2 Source operations 

On reception of a GN-DATA. request primitive with a Packet transport type parameter set to TSB, the source shall 
execute the following operations: 

1) create a GN-PDU with the T/GN6-SDU as payload and a TSB packet header (clause 8.6.3): 

a) set the fields of the Common Header (clause 9.3.2); 

b) set the fields of the TSB Extended Header (table 23); 

Table 23: Field settings for the TSB Extended Header 



Field name 


Field setting 


Description 


SN 


Actual value of the local sequence number 
(clause 7.3) 


Sequence number of the packet 


LT 


Value of Maximum lifetime parameter from 
the GA/-D/A7/\.requesf primitive 


Lifetime 


SOPV 


Actual values of the LPV (clause 7.2) 


Position vector of the local GeoAdhoc router 
(source of the GeoNetworking packet) 



£75/ 



45 



ETSI TS 102 636-4-1 VI. 1.1 (2011-06) 



2) if no neighbour exists, i.e. the LocT does not contain a LocTE with the IS_NEIGHBOUR flag set to TRUE, 
then buffer the TSB packet in the BC forwarding packet buffer and omit the execution of further steps; 

3) if the optional Repetition interval parameter in the GN-DATA. request parameter is set: 

a) save the TSB packet; 

b) retransmit the packet with period as specified in Repetition interval until the maximum lifetime of the 
packet is expired; 

NOTE 1 : The lifetime of the packet is specified in the Maximum lifetime parameter of the GN-DATA. request 
primitive. 

NOTE 2: For every retransmission, the operations need to be re -executed. 

4) execute media-dependent procedures: if the Communication profile parameter of the GN-DATA.request 
primitive is set to: 

a) UNSPECIFIED then omit this operation; 

b) is set to ITS-G5A then execute the operations as specified in [i.2]; 

5) pass the GN-PDU to the LL protocol entity via the IN interface and set the destination address to the Broadcast 
address of the LL entity. 

9.3.5.3 Forwarder and receiver operations 

On reception of a TSB packet, GeoAdhoc router shall execute the following operations: 

1) Common //eaiier processing (clause 9.3.3); 

2) execute duplicate packet detection (annex A); if the TSB packet is a duplicate, discard the packet and omit the 
execution of further steps; 

3) update the PV(SO) in the LocT with the SO PV fields of the TSB Extended Header (clause B.2); 

4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal SE GN_ADDR; 

5) pass the payload of the GN-PDU to the upper protocol entity by means of a GN-DATA. indication primitive 
with the parameter settings in table 24. 

Table 24: Parameter settings in the GN-DATA.indication primitive 
to indicate a received TSB paclcet 



Parameter name 


Parameter setting 


Upper protocol entity 


BTP if NH = 1 (BTP-A) 

BTP if NH = 2 (BTP-B) 

IPv6 if NH = 3 (IPv6) 

(NH encoding see table 5 in clause 8.5.3) 


Packet transport type 


TSB 


Source position vector 


Values of SO PVUom Extended Header 


Traffic class 


Value of 7C field from TSB Common Header 


Remaining packet lifetime 


Value of /.Tfrom TSB Common Header 


Length 


Length of the GN-PDU payload 


Data 


GN-PDU payload 



6) decrement the value of the HL field by one; if HL is decremented to zero, discard the GN-PDU and omit the 
execution of following operations; 

7) update the fields of the Common Header, i.e.: 

a) the HL field with the decremented HL value; 

b) the SE PV fields with the LPV (clause 7.2); 
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8) execute media-dependent procedures: if the Communication profile parameter of the GN-DATA.request 
primitive is set to: 

a) UNSPECIFIED then omit this operation; 

b) ITS-G5A then execute the operations as specified in [i. 2]; 

9) pass the GN-PDU to the LL protocol entity via the IN interface and set the destination address to the Broadcast 
address of the LL entity. 

9.3.6 SHB packet handling 

9.3.6.1 General 

This clause specifies the operations of a GeoAdhoc router to handle a SHB packet. The following clauses define the 
operations of the source and receiver. 

NOTE: SHB packets are not forwarded. Therefore, no forwarder operations are specified. 

9.3.6.2 Source operations 

On reception of a GN-DATA.request primitive with a Packet transport type parameter set to SHB, the source shall 
execute the following operations: 

1) create a GN-PDU with the T/GN6-SDU as payload and a SHB packet header (clause 8.6.4): 
a) set the fields of the Common Header (clause 9.3.2); 

2) if no neighbour exists, i.e. the LocT does not contain a LocTE with the IS_NEIGHBOUR flag set to TRUE, 
then buffer the SHB packet in the EC forwarding packet buffer and omit the execution of further steps; 

3) if the optional Repetition interval parameter in the GN-DATA.request parameter is set: 

a) save the SHB packet; 

b) retransmit the packet with period as specified in Repetition interval until the maximum lifetime of the 
packet is expired; 

NOTE 1 : The lifetime of the packet is specified in the Maximum lifetime parameter of the GN-DATA. request 
primitive. 

NOTE 2: For every retransmission, the operations need to be re -executed. 

4) execute media-dependent procedures: if the Communication profile parameter of the GN-DATA.request 
primitive is set to: 

a) UNSPECIFIED then omit this operation; 

b) is set to ITS-G5A then execute the operations as specified in [i.2]; 

5) pass the GN-PDU to the LL protocol entity via the IN interface and set the destination address to the Broadcast 
address of the LL entity. 

9.3.6.3 Receiver operations 

On reception of a SHB packet, the GeoAdhoc router shall execute the following operations: 

1) Common //eaJer processing (clause 9.3.3); 

2) pass the payload of the GN-PDU to the upper protocol entity by means of a GN-DATA. indication primitive 
with the parameter settings in table 25. 
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Table 25: Parameter settings in thie GN-DATA.indication primitive 
to indicate a received SIHB pacltet 



Parameter name 


Parameter setting 


Upper protocol entity 


BTP if NH = 1 (BTP-A) 

BTP if NH = 2 (BTP-B) 

IPv6 if NH = 3 (IPv6) 

(NH encoding see table 5 in clause 8.5.3) 


Packet transport type, 


SHB 


Source position vector 


Values of SE PVixom SHB Common Header 


Traffic class 


Value of 7C field from SHB Common Header 


Maximum lifetime 


Value of /.7from SHB Common Header 


Length 


Length of the GN-PDU payload 


Data 


GN-PDU payload 



9.3.7 GeoBroadcast packet handling 



9.3.7.1 



General 



This clause specifies the operations of a GeoAdhoc router to handle a GeoBroadcast packet. The following clauses 
define the operations of the source and forwarder/receiver. 

NOTE: In GeoBroadcast, a forwarder acts also always as a receiver. Therefore, the roles are not distinguished. 

9.3.7.2 Source operations 

On reception of a GN-DATA. request primitive with a Packet transport type parameter set to GeoBroadcast, the source 
shall execute the following operations: 

1) create a GN-PDU with the T/GN6-SDU as payload and a GeoBroadcast packet header (clause 8.6.5): 

a) set the fields of the Common Header (clause 9.3.2); 

b) set the fields of the GeoBroadcast Extended Header (table 26); 

Table 26: Field settings for the GeoBroadcast Extended Header 



Field name 


Field setting 


Description 


SN 


Actual value of the local sequence number 
(clause 7.3) 


Sequence number of the packet 


LT 


Value of Maximum lifetime parameter from 
the GA/-D/A T/\. requesf primitive 


Lifetime 


SOPV 


Actual values of the LPV (clause 7.2) 


Position vector of the local GeoAdhoc router 
(source of the GeoNetworking packet) 


GeoAreaPos 
Latitude 


GeoAreaPos Latitude from 
GN-DATA. request primitive 


GeoArea Area specification according to 
EN 302 931 [7] 


GeoAreaPos 
Longitude 


GeoAreaPos Longitude from 
GN-DATA.request primitive 


GeoArea Area specification according to 
EN 302 931 [7] 


Distance a 


Distance a from G/V-D/A 77\. requesf primitive 


GeoArea Area specification according to 
EN 302 931 [71 


Distance b 


Distance a from G/V-D/A 77\. requesf primitive 


GeoArea Area specification according to 
EN 302 931 [7] 


Angle 


Angle from GA/-D/\77\.requesf primitive 


GeoArea Area specification according to 
EN 302 931 [7] 


Reserved 


Reserved. Set to 





2) if no neighbour exists, i.e. the LocT does not contain a LocTE with the IS_NEIGHBOUR flag set to TRUE, 
then buffer the GeoBroadcast packet in the BC forwarding packet buffer and omit the execution of further 
steps; 
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3) if the optional Repetition interval parameter in the GN-DATA. request parameter is set: 

a) save the GeoBroadcast packet; 

b) retransmit the packet with period as specified in Repetition interval until the maximum lifetime of the 
packet is expired; 

NOTE 1 : The lifetime of the packet is specified in the Maximum lifetime parameter of the GN-DATA. request 
primitive. 

NOTE 2: For every retransmission, the operations need to be re -executed. 

4) determine the link-layer address LL_ADDR_NH of the next hop (annex D): 

a) if the MIB attribute itsGnGeoBroadcastForwardingAlgorithm is set to (UNSPECIFIED), execute the 
Simple GeoBroadcast with line forwarding algorithm as specified in clause D.2; 

b) if the MIB attribute itsGnGeoBroadcastForwardingAlgorithm is set to 1 (SIMPLE), execute the Simple 
GeoBroadcast with line forwarding algorithm as specified in clause D.2; 

5) if LL_ADDR_NH = 0, then buffer the GeoBroadcast packet in the BC forwarding packet buffer and omit the 
execution of further steps; 

6) execute media-dependent procedures: if the Communication profile parameter of the GN-DATA.request 
primitive is set to: 

a) UNSPECIFIED then omit this operation; 

b) is set to ITS-G5A then execute the operations as specified in [i.2]; 

7) pass the GN-PDU to the LL protocol entity via the IN interface and set the destination address to the LL 
address of the next hop LL_ADDR_NH. 

9.3.7.3 Forwarder and receiver operations 

On reception of a GeoBroadcast packet, the GeoAdhoc router shall execute the following operations: 

1) Common //eaiier processing (clause 9.3.3); 

2) execute duplicate packet detection (annex A); if the GeoBroadcast packet is a duplicate, discard the packet and 
omit the execution of further steps; 

3) update the PV(SO) in the LocT with the SO PV fields of the GeoBroadcast Extended Header (clause B.2); 

4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal SB GN_ADDR; 

5) determine the link-layer address LL_ADDR_NH of the next hop (annex E): 

a) if the MIB attribute itsGnGeoBroadcastForwardingAlgorithm is set to (UNSPECIFIED), execute the 
Simple GeoBroadcast with line forwarding algorithm as specified in clause D.2; 

b) if the MIB attribute itsGnGeoBroadcastForwardingAlgorithm is set to 1 (SIMPLE), execute the Simple 
GeoBroadcast with line forwarding algorithm as specified in clause D.2; 

6) if LL_ADDR_NH = 0, then buffer the GeoBroadcast packet in the BC forwarding packet buffer and omit the 
execution of further steps; 

f{x v1>0 

7) if ^ ' -^ ' (GeoAdhoc router is inside or at the border of the geographical area) pass the pay load of the 

GN-PDU to the upper protocol entity by means of a GN-DATA. indication primitive with the parameter settings 
in table 27; 

NOTE: If the GeoAdhoc router is outside the geographical area, the GN-PDU will not be passed to the ITS 
Facilities layer. 
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Table 27: Parameter settings in thie GN-DATA.indication primitive 
to indicate a received GeoBroadcast pacltet 



Parameter name 


Parameter setting 


Upper protocol entity 


BTP if NH = 1 (BTP-A) 

BTP if NH = 2 (BTP-B) 

IPv6 if NH = 3 (IPv6) 

(NH encoding see table 5 in clause 8.5.3) 


Packet transport type, 


GeoBroadcast 


Destination 


GeoArea (GeoPos, distance a, distance b, angle) 


Source position vector 


Values of SO P\/from Extended Header 


Traffic class 


Value of 7C field from GeoBroadcast Common Header 


Remaining packet lifetime 


Value of /.7from GeoBroadcast Common Header 


Length 


Length of the GN-PDU payload 


Data 


GN-PDU payload 



8) decrement the value of the HL field by one; if HL is decremented to zero, discard the GN-PDU and omit the 
execution of following operations; 

9) update the fields of the Common Header, i.e.: 

a) the HL field with the decremented HL value; 

b) the SE PV fields with the LPV (clause 7.2); 

10) execute media-dependent procedures: if the Communication profile parameter of the GN-DATA.request 
primitive is set to: 

a) UNSPECIFIED then omit this operation; 

b) ITS-G5A then execute the operations as specified in [i. 2]; 

11) pass the GN-PDU to the LL protocol entity via the IN interface and set the destination address to the LL 
address of the next hop LL_ADDR_NH. 



9.3.8 GeoAnycast packet handling 



9.3.8.1 



General 



This clause specifies the operations of a GeoAdhoc router to handle a GeoAnycast packet. The following clauses define 
the operations of the source and forwarder/receiver. 

The operations for GeoAnycast packet handling are similar to those for GeoBroadcast packet. 



9.3.8.2 



Source operations 



The operations of the source of a GeoAnycast packet are identical with the source of a GeoBroadcast packet as 
specified in clause 9.3.7.2, except the operation in step 5. Instead, the source shall execute the following operation: 

1) determine function F(x,y) as specified in [7] clause 5: 

a) if F[x, y)<0 (GeoAdhoc router is outside the geographical area) and the MIB attribute 
itsGnGeoAreaLineForwarding is set to TRUE, execute the GeoUnicast forwarding algorithm and 
determine the link-layer address LL_ADDR_NH of the next hop (annex C); 

b) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to (UNSPECIFIED), execute the GF 
algorithm as specified in clause C.2; 

c) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 1 (GREEDY), execute the GF 
algorithm as specified in clause C.2; 

d) if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 2 (CBF), execute the CBF algorithm 
as specified in clause C.3. 
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9.3.8.3 Forwarder and receiver operations 

On reception of a GeoAnycast packet, the GeoAdhoc router shall execute the following operations: 

1) Common Header processing (clause 9.3.3); 

2) execute duplicate packet detection (annex A); if the GeoAnycast packet is a duplicate, discard the packet and 
omit the execution of further steps; 

3) update the PV(SO) in the LocT with the SO PV fields of the GeoAnycast Extended Header (clause B.2); 

4) set the IS_NEIGHBOUR(SO) flag to FALSE if SO GN_ADDR does not equal SE GN_ADDR; 

5) determine function F(x,y) as specified in [7] clause 5: 

fix vl< 

a) if ^ ' -^ '' (GeoAdhoc router is outside the geographical area) and the MIB attribute 

itsGnGeoAreaLinePorwarding is set to TRUE, execute the GeoUnicast forwarding algorithm and 
determine the link-layer address LL_ADDR_NH of the next hop (annex C): 

i. if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to (UNSPECIFIED), execute 
the GF algorithm as specified in clause C.2; 

ii. if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 1 (GREEDY), execute the GF 
algorithm as specified in clause C.2; 

iii. if the MIB attribute itsGnGeoUnicastForwardingAlgorithm is set to 2 (CBF), execute the CBF 
algorithm as specified in clause C.3; 

f(x v1> 

b) if V ' // (GeoAdhoc router is inside or at the border of the geographical area) pass the payload of 

the GN-PDU to the upper protocol entity by means of a GN-DATA.indication primitive with the 
parameter settings in table 27. 

NOTE: If the GeoAdhoc router is outside the geographical area, the GN-PDU will not passed to the ITS Facilities 
layer. 

Table 28: Parameter settings in the GN-DATA.indication primitive 
to indicate a received GeoAnycast pacl<et 



Parameter name 


Parameter setting 


Upper protocol entity 


BTP if NH = 1 (BTP-A) 

BTP if NH = 2 (BTP-B) 

IPv6 if NH = 3 (IPv6) 

(NH encoding see table 5 in clause 8.5.3) 


Packet transport type, 


GeoAnycast 


Destination 


GeoArea (GeoPos, distance a, distance b, angle) 


Source position vector 


Values of SO PV from Extended Header 


Traffic class 


Value of TO field from GeoAnycast Common Header 


MaximumRemaining packet lifetime 


Value of LT from GeoAnycast Common Header 


Lengtfi 


Length of the GN-PDU payload 


Data 


GN-PDU payload 
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Conformance and test methods 



Conformance and test methods for GeoNetworking are not specified in the present document. 
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Annex A (normative): 
Duplicate packet detection 



With multi-hop communication in an ad-hoc network, a GeoAdhoc router can receive multiple copies of the same 
packet. Reasons for packet duplications are the forwarding of the packet from multiple GeoAdhoc routers or routing 
loops. In order to control (e.g. prevent) the forwarding of duplicate packets, the GeoNetworking protocol uses a 
mechanism for duplicate packet detection. 

The GeoNetworking protocol applies duplicate packet detection to multi-hop packets (GeoUnicast, TSB, GeoBroadcast, 
GeoAnycast, LS Request, LS Reply). The mechanism is based on sequence numbers and implies that every 
GeoNetworking packet carries a sequence number in its header. 

NOTE 1 : For single-hop packets (BEACON and SHB) duplicate packet detection will not be applied and those 
packets do not carry SN fields. 

For duplicate packet detection, a GeoAdhoc router maintains the sequence number of the last packet from the source 
that was identified as 'not duplicated' in its LocT, i.e. SNGN_ADDRas defined in clause 7.1.2. When the GeoAdhoc router 
processes a GeoNetworking packet, it compares the value of the SN field carried in the GeoNetworking packet SN(P) 
and SNso.sAv- If SN(P) is greater than SNgn_addr the received packet is regarded as 'not duplicated' and SNso.sav is 
updated. 

NOTE 2: The GeoNetworking protocol does not provide packet re-ordering. Due to the simple duplicate packet 
detection, out-of-sequence packets will be discarded. 

The sequence numbers in the GeoNetworking protocol are limited in the number of bits that represent the sequence 
number. In order to handle the wrap around of sequence numbers (that the sequence number is incremented from the 
maximum possible value to zero), the following algorithm shall be used: 

-- P is the received GeoNetworking packet 

-- SN{P) is the sequence number in the received GeoNetworking packet 

-- SNso.sAv is the last received sequence number from source SO saved by 

the local GeoAdhoc router 
-- SN_MAX is the maximum sequence number = 2^16-1 
IF {{{SN{P) > SNso.sAv) AND {{SN{P) - SNso.sav) <= SN_MAX/2)) OR 

{{SNso.sAv > SN(P)) AND {{SNso.sav " SN{P)) > SN_MAX/2))) THEN 

SN{P) is greater than SNso.sav 

P is not a duplicate packet 

SNso.sav ^ SN{P) 
ELSE 

SN{P) is not greater than SNso.sav 

P is a duplicate 
END IF 
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Annex B (normative): 
Position vector update 

B.1 Overview 

The position vector update is executed in the GeoNetworking forwarding process (clause 9.3) when a PV in a LocTE is 
updated by PV carried in a GeoNetworking packet header. The algorithm ensures that always the newer PV is used 
indicated by the timestamp that is contained in the PV. 

The algorithm is utilized in two cases: 

1) When a GeoNetworking packet is received, the forwarding procedure updates the PV in the LocT by the PV 
carried in the GeoNetworking packet. 

2) When a GeoNetworking packet is forwarded, the forwarding procedure updates the PV in the packet to be 
forwarded by the PV in the LocT. 

The algorithm makes use of the timestamp that is associated with the position information and is part of the position 
vector fields. It handles the wrap around of the timestamp values that occur due to the limited number of bits that 
represent a timestamp. 

NOTE: With a 32 bit timestamp in [ms], a wrap around occurs after 50 days: 
(((((2^^) - 1) / 1 000) / 60) / 60) / 24 = 49,7102696 



B.2 Update of LocT position vector 

The following algorithm shall be applied to update a PV in the LocT. The algorithm shall also reset the lifetime of the 
location table entry T(LocTE) (clause 7.1.3). 

-- RP is the received GeoNetworking packet 

-- PVrp is the position vector in the received GeoNetworking packet 

-- PVloct is the position vector in the LocT to be updated 

-- TSTpv,EP is the timestamp for the position vector in the received 

GeoNetworking packet 
-- TSTpv.LocT is the timestamp for the position vector in the location table 

to be updated 
-- TSnax is the maximum value of the timestamp = 2^32-1 
-- T (LocTE) is the lifetime of the location table entry 

-- itsGnLifetimeLocTE is the value of the MIB attribute itsGnLif etimeLocTE 
IF {{{TSTpv,EP > TSTpv.loct) and ((TSTpv,hp - TSTpv.loct) <= TST„ax/2)) OR 

{ {TSTpv.LocT > TSTpv,Rp) AND ((TSTpv.loct - TSTpv,Rp) > TST„„/2))) THEN 

TSTpv,RP is greater than TSTpv,loct 

PVloct *- PVrp 

T (LocTE) ^ value (ItsGnLifetimeLocTE) 
ELSE 

TSTpv,RP is not greater than TSTpv.loct 
END IF 
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B.3 Update of GeoNetworking packet position vector 

The following algorithm shall be applied to update a PV in a packet to be forwarded: 

-- FP is the GeoNetworking packet to be forwarded 

-- PVfp is the position vector in the GeoNetworking packet to be forwarded 

-- PVloct is the position vector in the LocT 

-- TSTpv,Fp is the timestamp for the position vector in the GeoNetworking 

packet to be forwarded 
-- TSTpv.LocT is the timestamp for the position vector in the location table 
-- TSmbx is the maximum value of the timestamp = 2^32-1 
IF ( ( (TSTpv.LocT > TSTpv,Fp) AND ((TSTpv.loct - TSTpv,Fp) <= TST„ax/2)) OR 

{{TSTpv,FP > TSTpv.loct) AND ((TSTpv,fp " TSTpv.loct) > TST„„/2))) THEN 

TSTpv.LocT is greater than TSTpv.fp 

PVfp *- PVloct 
ELSE 

TSTpv,Fp is not greater than TSTpv.loct 
END IF 
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Annex C (normative): 
GeoUnicast forwarding algorithms 

C.1 Overview 

The GeoUnicast forwarding algorithm is executed by a GeoAdhoc router to relay a packet to the next hop. 
The present document defines two GeoUnicast forwarding algorithms: 

• Greedy Forwarding (GF) algorithm (clause C.2); 

• Contention-based forwarding (CBF) algorithm (clause C.3). 

C.2 Greedy Forwarding algorithm 

With the Greedy Forwarding (GF) algorithm, the GeoAdhoc router uses the location information of the destination 
carried in the GeoUnicast packet header and selects one of the neighbours as the next hop. 

The algorithm applies the most forward within radius (MFR) policy, which selects the neighbour with the smallest 
geographical distance to the destination, thus providing the greatest progress when the GeoUnicast packet is forwarded. 

-- P is the GeoUnicast packet to be forwarded 

-- i is the i-th LocTE 

-- NH is the LocTE idenfified as next hop 

-- NH_LL_ADDR is the link layer address of the next hop 

-- LPV is the local position vector 

-- PVp is the destination position vector in the GeoNetworking packet to be forwarded 

-- PVi is the position vector of the i-th LocTE 

MFR = DIST{PVp, LPV) 

FOR {ie LocT) 

IF { i . I S_NE I GHBOUR ) THEN 

IF {DIST{PVp, PVi) < MFR) THEN 
NH ^ i 

MFR ^ DIST{PVp, PVi) 
END IF 

END IF 
ENDFOR 
IF {MFR < DIST{PVp, PVlpv) ) THEN 

SET NH_LL_ADDR = NH . LL_ADDR 
ELSEIF 

LOCAL OPTIMUM 

SET NH_LL_ADDR = 
END IF 

If no neighbour with greater progress than the local GeoAdhoc router exists, the packet has reached a local optimum. 



C.3 Contention-based forwarding algorithm 

With the Contention-based forwarding (CBF) algorithm, a receiver decides to be a forwarder of a GeoUnicast packet. 
This is in contrary to the sender-based forwarding scheme specified in clause C.2, where the sender determines the next 
hop. The CBF algorithm utilizes timer -based re-broadcasting with overhearing of duplicates in order to enable an 
implicit forwarding of a packet by the optimal node. 
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With CBF, the GeoAdhoc router broadcasts the GeoUnicast packet. All neighbours, which receive the packet, process 
it: the GeoAdhoc router buffers the packet in its CBF packet buffer and starts a timer with a timeout that is inversely 
proportional to the distance between the GeoAdhoc router's local position and the destination's positions. 

Equation 1: Calculation of timeout for buffering packets in the CBF packet buffer TO_CBF 



TO CBF ■■ 



TO CBF ^,^,^^-CZ^^-MAX-TO_CZ^F_M/A^^^^^ for Dist < DIST MAX 

DIST _MAX 



TO_CBF _MIN for DIST >Dist_ MAX 

where: 

TO_CBF_MIN is the minimum duration the packet shall be buffered in the CBF packet buffer. 

TO_CBF_MAX is the maximum duration the packet shall be buffered in the CBF packet buffer. 

DIST_MAX is the theoretical maximum communication range of the wireless access technology. 

TO_CBF_MIN and TO_CBF_MAX shall be set to the MIB attributes itsGnGeoUnicastCbfMinTime and 
itsGnGeoUnicastCbfMaxTime, respectively. If DIST_MAX is not defined in the specification of GeoNetworking 
media-dependent functionality for the specific ITS access technology (e.g. TS 102 636-4-2 [i.2]), it shall be set to the 
MIB attribute itsGnDefaultMaxCommunicationRange. 

Upon expiration of the timer, the GeoAdhoc router re-broadcasts the GeoUnicast packet. Before the timer expires, the 
GeoAdhoc router may receive a duplicate of the packet from a GeoAdhoc router with a shorter timeout, i.e. with a 
smaller distance to the destination. In this case, the GeoAdhoc router inspects its CBF packet buffer, stops the timer and 
removes the GeoUnicast packet from the CBF packet buffer. 

Compared to the GF algorithm (clause C.2), CBF has an implicit reliability mechanism at the cost of larger forwarding 
delay and additional processing. The reliability mechanism ensures that a packets is re -forwarded by an alternative 
forwarder if the theoretically optimal forwarder does not receive the packet, e.g. due to wireless link errors. 

The activity diagram of the CBF algorithm is depicted in figure C.l. 
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act CBF State machine 




Figure C.I : CBF activity diagram 

The pseudo-code of the algorithm is below: 

-- P is the GeoUnicast packet to be forwarded 

-- LPV is the local position vector 

-- PV_P is the destination position vector in the GeoNetworking packet 

to be forwarded 

-- B is the CBF packet buffer 

-- TO is the timeout that triggers the re-broadcast of the packet 

-- NH_LL_ADDR is the LL address of the next hop 

-- BCAST is the broadcast LL address 



IF {P IN B) THEN 

REMOVE P FROM B 

STOP TIMER 
ELSE 

ADD P TO B 

SET DIST = DIST{PV_P, LPV) 

SET TO 

START TIMER (TO) 
END IF 

IF {TIMER (TO) EXPIRES) THEN 
FETCH P FROM B 
IF {LocT IS EMPTY) THEN 

SET NH_LL_ADDR = 
ELSE 

SET NH_LL_ADDR = BCAST 
END IF 
END IF 



# Contending 

# New packet 

# Equation 1 



# No neighbors 
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Annex D (normative): 
GeoBroadcast forwarding algorithms 

D.1 Overview 

The GeoBroadcast forwarding algorithm is executed by a GeoAdhoc router to relay a packet to the next hop. 
The present document defines three forwarding algorithms: 

• Simple GeoBroadcast forwarding algorithm (clause D.2); 

• Advanced GeoBroadcast forwarding algorithm 1 (informative clause E.2); 

• Advanced GeoBroadcast forwarding algorithm 2 (informative clause E.3). 

The latter two algorithms are experimental and provided for informative purpose in the informative annex E. 

D.2 Simple GeoBroadcast forwarding algorithm with line 
forwarding 

The algorithm utilizes the function F(x,y) specified in [7] clause 5 in order to determine whether the GeoAdhoc router is 
located inside, at the border or outside the geographical target area carried in the GeoBroadcast packet header. If the 
GeoAdhoc router is inside or at the border of the area, the packet shall be re -broadcasted. If it is outside the area, the 
packet shall be forwarded by the GF algorithm specified in clause C.2. 

NOTE 1 : Packet duplicate detection is not part of the forwarding algorithm but of the packet handling operations. 

NOTE 2: As defined in [7] clause 5, 

= 1 for X = and y = (at the centre point) 
> inside the geographical area 
= at the border of the geographical area 
< outside the geographical area 



F{x, y) 



-- P is the GeoNetworking packet to be forwarded 

-- LAT and LONG are latitude and longitude of the LPV, respectively 

-- DAp is the destination area in the GeoNetworking packet to be forwarded 

-- A is the centre point of the destination area DAfp 

-- LL_ADDR is the link layer address that identifies the next hop 

of the GeoNetworking packet 

-- BCAST is the broadcast LL address 

-- GREEDY {) is the GF algorithm 

LL_ADDR = 

Calculate F{LAT, LONG) 

IF {F>0) THEN 

RETURN LL_ADDR = BCAST 
ELSE 

RETURN LL_ADDR = GREEDY (A) or 
END IF 
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Annex E (informative): 

Advanced GeoBroadcast forwarding algorithms 



E.1 Overview 



This clause specifies two advanced GeoBroadcast forwarding algorithms (clauses E.2 and E.3). These algorithms are 
experimental and provided for informative purpose. 



E.2 Advanced GeoBroadcast forwarding algorithm 1 

The Advanced GeoBroadcast forwarding algorithml relies on three main mechanisms: 

1) CBF is used to deal with uncertainties in terms of reception failure caused by node mobility, fading 
phenomena and colUsions on the wireless medium. 

2) In order to minimize the forwarding delay, CBF is complemented with the selection of one specific forwarder 
at the sender, referred to as next hop. Upon reception of the packet, the next hop - in case of correct reception - 
forwards the message immediately. 

3) the reliability of the dissemination process is increased by a controlled packet retransmission scheme within 
the geographical target area. 

The activity of the advanced GeoBroadcast forwarding algorithm is depicted in figure E.l. 
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act Advanced GeoBroadcast Forwarding State machine 




Figure E.I : Activity diagram of Advanced GeoBroadcast algorithm 1 
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For the selection of the next hop, the GF algorithm (clause C.3) should be used, where the destination position is a point 
at the border of the geographical area farthest from the position of the source node. 

The pseudo-code of the algorithm is below: 

-- P is the GeoBroadcast packet to be forwarded 

-- DEST_LL_ADDR is the LL destination address carried in P 

-- B is the CBF packet buffer 

-- LPV is the Local Position Vector 

-- LAT and LONG are latitude and longitude of the LPV, respectively 

-- L_LL_ADDR is the local LL address 

-- NH is the LocTE idenfified as next hop 

-- NH_LL_ADDR is the LL address of the next hop 

-- BCAST is the broadcast LL address 

-- i is the i-th LocTE 

-- PVi is the PV of the i-th LocTE 

-- INOUT is determined by the area function specified in [7] clause 5 



L LL ADDR) THEN 



SET NH_LL_ADDR = 

SET INOUT = F{LAT, LONG) 

IF {INOUT>0) THEN 

IF {P NOT IN B) THEN 
ADD P TO B 
IF {DEST_LL_ADDR 
SET TO = MAX 
SET COUNTER = 1 

SET NH_LL_ADDR = FindNextHop { ) 
ELSE 

SET TO 

SET COUNTER = 
SET NH_LL_ADDR = 
END IF 

START TIMER (TO) 
ELSE 

IF {COUNTER > MAX_COUNTER) THEN 
REMOVE P FROM B 
STOP TIMER 
SET NH_LL_ADDR = 
ELSE 

SET TO 

SET COUNTER++ 
SET NH_LL_ADDR = BCAST 
START TIMER (TO) 
END IF 
END IF 

RETURN NH_LL_ADDR 
ELSE 

DROP P 
RETURN 
END IF 



# See [7] clause 5 

# Inside or at border of the geogr. area 

# New packet, not contending 



# TO_CBF_MAX {See equation 1) 



# See equation 1 



# Contending 
# Cancel contention 



# See equation 1 



# Outside of geographical area 



IF {TIMER EXPIRES) THEN 

IF {COUNTER > MAX_COUNTER) THEN 

REMOVE P FROM B 

STOP TIMER 

SET NH_LL_ADDR = 
ELSE 

SET TO 

SET COUNTER++ 

SET NH_LL_ADDR = BCAST 

START TIMER {TO) 
END IF 

RETURN NH_LL_ADDR 
END IF 



# Cancel contention 



# See equation 1 



PROCEDURE : FindNextHop { ) 
MFR = 
LL_ADDR = 
FOR {iG LocT) 

IF {i.IS_NEI GHBOUR ) THEN 

IF {{MFR != 0) AND {DIST {TARGET_POS, PVi) < MFR)) THEN 
NH ^ i 

MFR ^ DIST{PVp, PVi) 
LL_ADDR = i . LL_ADDR 
END IF 
END IF 
ENDFOR 
RETURN LL ADDR 
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E.3 Advanced GeoBroadcast forwarding algorithm 2 

The Advanced GeoBroadcast forwarding algorithm 2 is based on CBF to deal with uncertainties in terms of reception 
failure caused by node mobility, fading phenomena and collisions on the wireless medium. In addition to improve 
connectivity, a sectoral suppression algorithm is used. Details are available in the publication about MHVB in annex J. 

The activity diagram of the advanced GeoBroadcast forwarding algorithm 2 is depicted in figure E.2. 




Figure E.2: Activity diagram of Advanced GeoBroadcast algorithm 2 
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-- P is the GeoNetworking packet to be forwarded 

-- Lf is the list of forwarding packet 

-- P' is the GeoNetworking packet stored in Lf 

-- Lc is the list of PID completed {e.g. already forwarded) 

-- POS is {latitude, longitude} of this node's LPV 

-- POS_s is {latitude, longitude} of the sender node's PV 

-- GA is the geographical area to which this packet is supposed to be 

forwarded 

-- PID is the {GN_ADDR, SN} of the GeoNetworking packet 

-- DIST_MAX is the theoretical maximum communication range 

-- CalcDist {POSl, P0S2) is the function to calculate the distance between POSl and P0S2 

-- CalcAngle {POS_b, P0S_1, P0S_2) is the function to calculate the angle Z {P0S_1) - {POS_b) - {P0S_2) 

(or cosine value) 

-- CalcTimer (DIST) corresponds to Equation 1 in C.3 

-- ANGLE_TH is a certain threshold value {e.g. 30 [degree] or cosine value) 

/*** Receive GeoBroadcast packet ***/ 
ReceivePacket {P) : 

Extract {POS_s, PID, GA} from P 
IF {PID e Lc) THEN 
DROP P 
RETURN 
END IF 

Calculate F {POS->longitude, POS->latitude) based on GA /* Refer D.2 */ 
IF {F>0) THEN 

IF {P' G Lf where P'->PID = P->PID) THEN /* Already registered in the forwarding packet list 
*/ 

Set POS_s' to P'->POS_s 

ANGLE = CalcAngle {POS_s', POS, POS_s) 

DIST_1 = CalcDist {POS_s', POS) /* Distance with respect to the sender of P'*/ 

DIST_2 = CalcDist {POS_s', POS_s) /* Distance between senders of P and P'*/ 

IF {ANGLE < ANGLE_TH && DIST_1 < DIST_2 && DIST_2 < DIST_MAX) THEN 

Remove P ' from Lf 

Cancel TIMER {P' ) 

Add PID into Lc 
END IF 



DROP 


' P 




ELSE 






DIST 


' = CalcDist {POS, 


POS_s) 


Set 


TO = CalcTimer {DIST) 


Set 


TIMER {P, TO) 




Add 


P into Lf 




END IF 






ELSE 






DROP P 






END IF 







/*** CBF timer expires ***/ 
TimerExpiration {P) : 

Remove P from Lf 

Add PID into Lc 

Update P->POS 

FORWARD P 
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Annex F (normative): 
GeoNetworking protocol constants 

Table F.l specifies the GeoNetworking protocol constants that shall be supported by GeoAdhoc routers. 
The protocol constants represent MIB attributes. The MIB is specified in annex G in ASN-1. 

Table F.l : GeoNetworking MIB attribute types 



MIB attribute type 


Default/initial value 


Comment 


itsGnLocalGnAddr 


1 


GeoNetworking address of the GeoAdhoc 
router 


itsGnLocalAddrConfMethod 


AUTO (0) 
MANAGED (1) 


AUTO: Local GN ADDR is configured from 

MIB 

MANAGED: Local GN_ADDR is configured 

via the GN-MGMTt primitive (annex 1) 


itsGnProtocolVersion 


TS 102 636-4-1 (V1.1.1)(0) 


Version of the GeoNetworking protocol set 
in the GeoNetworking protocol headers 


itsGnStationlype 


Vehicle ITS Station (0) 
Roadside ITS Station (1) 


Type of ITS Station 


itsGnMinimumUpdateFrequencyLPV 


Vehicle ITS Station (1 000) 
Roadside ITS Station (0) 


Minimum update frequency of local position 
vector (LPV) in ms 


itsGnMaxSduSize 


1 398 


Maximum size of GN-SDU [bytes] 

1 500- GN MAX (88) - GNSEC MAX (0) 


itsGnMaxGeoNetworkingHeaderSize 


88 


GN_MAX: Maximum size of 
GeoNetworking header [bytes] 
Determined by the GeoUnicast header as 
defined in clause 8.6.2 


ItsGnLifetimeLocTE 


20 


Lifetime of location table entry [s] 


itsGnLocationServiceMaxRetrans 


10 


Maximum number of retransmissions of LS 
Request packets 


itsGnLocationServiceRetransmitTimer 


1 000 


Duration of Location service retransmit 
timer [ms] 


itsGnLocationServicePacketBufferSize 


1 024 


Size of Location service packet buffer 
[Byte] 


itsGnBeaconServiceRetransmitTimer 


3 000 


Duration of Beacon service retransmit timer 
[ms] 


itsGnBeaconServiceMaxJitter 


itsGnMaxPacketLifetime/4 


Maximum beacon jitter [ms] 


itsGnDefaultHopLimit 


10 


Default hop limit indicating the maximum 
number of hops a packet travels 


itsGnMaxPacketLifetime 


600 


Upper limit of the maximum lifetime [s] 


itsGnMinPacketRepetitionlnterval 


100 


Lower limit of the packet repetition interval 
[ms] 


itsGnGeoUnicastForwardingAlgorithm 


UNSPECIFIED (0) 
GREEDY (1) 
CBF (2) 


Default GeoUnicast forwarding algorithm 


ItsGnGeoBroadcastForwardingAlgorithm 


UNSPECIFIED (0) 
SIMPLE (1) 


Default GeoBroadcast forwarding algorithm 


itsGnGeoUnicastCbfMinTime 


1 


Minimum duration a packet shall be 
buffered in the CBF packet buffer [ms] 


itsGnGeoUnicastCbfMaxTime 


100 


Maximum duration a packet shall be 
buffered in the CBF packet buffer [ms] 


itsGnDefaultMaxGommunicationRange 


1 000 


Default theoretical maximum 
communication range [m] 


itsGnGeoAreaLineForwarding 


DISABLED (0) 
ENABLED (1) 


Forwarding of GeoBroadcast/GeoAnycast 
packet if GeoAdhoc router is located 
outside the GeoArea. 


itsGnUcForwardingPacketBufferSize 


256 


Size of UC forwarding packet buffer 
[Kbytes]. 


itsGnBcForwardingPacketBufferSize 


1 024 


Size of BC forwarding packet buffer 
[Kbytes]. 
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MIB attribute type 


Default/initial value 


Comment 


itsGnCbfPacketBufferSize 


256 


Size of CBF pacl<et buffer [Kbytes] 


itsGnTrafficClassRelevance 


3 


Forwarding: Default traffic class Relevance 


itsGnTrafficClassReliability 


Medium (10) 


Forwarding: Default traffic class Reliability 


itsGnTrafficClassLatency 


Medium (10) 


Forwarding: Default traffic class Latency 
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Annex G (normative): 

ASN.1 encoding of the GeoNetworking MIB 



G.1 Use of modules 



The ASN. 1 module of the present document is ITSGN { itu-t(O) identified-organization(4) etsi(O) itsgn(2636-4)} as 
specified in the following clause. The encoding shall be packet encoding rules (PER) as specified in [8]. 



G.2 ASN.1 module 



***************************************************************************** 

-- * ETSI TC ITS TS 102 636-4 GeoNetworking MIB 

***************************************************************************** 

ITSGN-MIB DEFINITIONS: :=BEGIN 

IMPORTS 

MODULE-IDENTITY, OBJECT-TYPE, 

Unsigned32, Integer32, 

enterprises FROM SNMPv2-SMI 

SnmpAdminString FROM SNMP-FRAMEWORK-MIB 

TEXTUAL-CONVENTION FROM SNMPv2-TC 

Interfacelndex FROM IF-MIB; 

***************************************************************************** 

-- * MODULE IDENTITY 

***************************************************************************** 

itsGn MODULE- IDENTITY 

LAST-UPDATED " 2 01103310000Z" 

ORGANIZATION "ETSI Technical Committee ITS WG3 " 

CONTACT- INFO 

"WG Email: ITS_WG3@LIST.ETSI.ORG" 
DESCRIPTION 

"The MIB module for TS 102 636-4 (GeoNetworking) entities 
itu-t{0) . identif ied-organization (4) .etsi{0) . itsgn (26364) 
II 

REVISION "201103310000Z" 

DESCRIPTION "TS 102 636-4-1 VO . 1 . 2 " 

REVISION "201011160000Z" 

DESCRIPTION "TS 102 636-4-1 VO.0.9" 

REVISION "201007140000Z" 

DESCRIPTION "TS 102 636-4-1 VO.0.7" 

REVISION "201006140000Z" 

DESCRIPTION "Initial version: TS 102 636-4-1 VO . . 6 " 
::= { enterprises 13019 26364} 

***************************************************************************** 

-- * PRIMARY GROUPS 

***************************************************************************** 



itsGnObjects OBJECT IDENTIFIER 
itsGnStatistics OBJECT IDENTIFIER 
itsGnConformance OBJECT IDENTIFIER 



{ itsGn 1 } 
{ itsGn 2 } 

{ itsGn 3 } 



***************************************************************************** 

* SUB GROUPS 
***************************************************************************** 

itsGnMgmt OBJECT IDENTIFIER ::= { itsGnObjects 1 } 

***************************************************************************** 

* SUB SUB GROUPS 
***************************************************************************** 



itsGnSystem OBJECT IDENTIFIER 

itsGnConfig OBJECT IDENTIFIER 

itsGnLocationService OBJECT IDENTIFIER 



{ itsGnMgmt 1 } 
{ itsGnMgmt 2 } 
{ itsGnMgmt 3 } 
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itsGnBeaconService OBJECT IDENTIFIER ::= { itsGnMgmt 4 } 
itsGnPacketForwarding OBJECT IDENTIFIER ::= { itsGnMgmt 5 } 



***************************************************************************** 

* TEXTUAL CONVENTIONS 
***************************************************************************** 

GnAddress ::= TEXTUAL-CONVENTION 
DISPLAY-HINT " 2x : 2x : 2x : 2x" 
STATUS current 
DESCRIPTION 

"Represents a GeoNetworking address: 



Octets Contents Encoding 
1-8 GN address network-byte order" 
SYNTAX OCTET STRING {SIZE (8)) 



***************************************************************************** 

-- * GN OBJECTS GROUP 

***************************************************************************** 

***************************************************************************** 

-- * GN SYSTEM GROUP 

***************************************************************************** 

itsGnlfTable OBJECT-TYPE 

SYNTAX SEQUENCE OF ItsGnlfEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 

"A table representing the interfaces that will be used by the 

GeoAdhoc router for communication. Each entry in this table 

represents a configured egress interface. 



:= { itsGnSystem 1 } 



itsGnlfEntry OBJECT-TYPE 

SYNTAX ItsGnlfEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 

"An entry in the interface table. It 

represents a single interface entry. 

II 

INDEX { itsGnlflndex } 
: := { itsGnlfTable 1 } 

ItsGnlfEntry : := 
SEQUENCE { 

itsGnlflndex Interf acelndex, 

itsGnlf Priority Unsigned32, 

itsGnlf Description SnmpAdminString 
} 

itsGnlflndex OBJECT-TYPE 

SYNTAX Interfacelndex 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 

"The index of the interface of the GeoAdhoc router. 

II 

: := { itsGnlfEntry 1 } 

itsGnlfPriority OBJECT-TYPE 

SYNTAX Unsigned32 {0..255) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"The priority configured to the interface. 

This value will be configured to a value between 

and 255. 

11 

: := { itsGnlfEntry 2 } 
itsGnlfDescription OBJECT-TYPE 
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SYNTAX SnmpAdminString 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"A human- readable textual description of the 

interface on the GeoAdhoc router. 

Tl 

: := { itsGnlf Entry 3 } 

***************************************************************************** 

-- * GN CONFIGURATION SUB GROUP 

***************************************************************************** 

itsGnLocalGnAddr OBJECT-TYPE 

SYNTAX GnAddress 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"GeoNetworking address of the GeoAdhoc router." 
: := { itsGnConfig 1 } 

it sGnLocalAddrConf Method OBJECT-TYPE 
SYNTAX INTEGER { 
autod) , 
managed (2) 

} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Local address configuration method 
AUTO: Local GN_ADDR is configured from MIB 

MANAGED: Local GN_ADDR is configured via the GN-MGMTt primitive {annex G) '' 
: := { itsGnConfig 2 } 

itsGnProtocolVersion OBJECT-TYPE 

SYNTAX Unsigned32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"GeoNetworking protocol version." 
: := { itsGnConfig 3 } 

itsGnStationType OBJECT-TYPE 
SYNTAX INTEGER { 

vehicleltsStation (0) , 
roadsideltsStation (1) 

} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"ITS Station type. " 
: := { itsGnConfig 4 } 

itsGnMinUpdateFrequencyLPV OBJECT-TYPE 

SYNTAX Integer32 {0 . .65635) 

UNITS "milliseconds" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

" Minimum update frequency of local position vector (LPV) in ms . " 
: := { itsGnConfig 5 } 

itsGnMaxSduSize OBJECT-TYPE 

SYNTAX Integer32 {0 . .65635) 

UNITS "Bytes" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

" Maximum size of GN-SDU in bytes." 
: := { itsGnConfig 6 } 

itsGnMaxGeoNetworkingHeaderSize OBJECT-TYPE 
SYNTAX Integer32 {0 . .65635) 
UNITS "Bytes" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Maximum size of GeoNetworking header in bytes." 
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: := { itsGnConfig 7 } 

itsGnLifetimeLocTE OBJECT-TYPE 

SYNTAX Integer32 {0 . .65635) 
UNITS "Seconds" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

" Location table maintenance: Lifetime of an entry in the location table 
in s . " 
: := { itsGnConfig 8 } 

***************************************************************************** 

-- * GN LOCATION SERVICE SUB GROUP 

***************************************************************************** 

itsGnLocationServiceMaxRetrans OBJECT- TYPE 

SYNTAX Integer32 {0. .255) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Location service: Maximum number of retransmissions for a LS Request." 
: := { itsGnLocationService 1 } 

itsGnLocationServiceRetransmitTimer OBJECT- TYPE 

SYNTAX Integer32 {0 . .65535) 

UNITS "milliseconds" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Location service: Duration of LS request retransmit timer in ms . " 
: := { itsGnLocationService 2 } 

itsGnLocationServicePacketBuf ferSize OBJECT- TYPE 

SYNTAX Integer32 {0 . .65535) 

UNITS "Bytes" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Location service: Size of LS packet buffer in bytes." 
: := { itsGnLocationService 3 } 

***************************************************************************** 

-- * GN BEACON SERVICE SUB GROUP 

***************************************************************************** 

itsGnBeaconServiceRetransmitTimer OBJECT- TYPE 

SYNTAX Integer32 {0 . .65535) 

UNITS "milliseconds" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Beacon service: Duration of Beacon retransmit timer in ms . " 
: := { itsGnBeaconService 1 } 

itsGnBeaconServiceMax Jitter OBJECT- TYPE 

SYNTAX Integer32 {0 . .65535) 

UNITS "milliseconds" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Beacon service: Maximum Beacon jitter in ms . " 
: := { itsGnBeaconService 2 } 

***************************************************************************** 

-- * GN PACKET FORWARDING SUB GROUP 

***************************************************************************** 

itsGnDefaultHopLimit OBJECT-TYPE 

SYNTAX Integer32 {0 . .255) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

" Default hop limit for forwarding." 
: := { itsGnPacketForwarding 1 } 

itsGnMaxLifetime OBJECT-TYPE 

SYNTAX Integer32 {0 . .6300) 
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UNITS "seconds" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Upper limit of the maximum lifetime of a packet in s." 
: := { itsGnPacketForwarding 2 } 

itsGnMinRepetitionlnterval OBJECT-TYPE 

SYNTAX Integer32 {0 . .1000) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Lower limit of the packet repetition interval in ms . " 
: := { itsGnPacketForwarding 3 } 

itsGnGeoUnicastForwardingAlgorithm OBJECT- TYPE 
SYNTAX INTEGER { 

unspecified (0), 
greedy (1) , 
cbf (2) 

} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"GeoUnicast forwarding algorithm." 
: := { itsGnPacketForwarding 4 } 

itsGnGeoBroadcastForwardingAlgorithm OBJECT- TYPE 
SYNTAX INTEGER { 

unspecified (0), 
simple (1) , 
advanced (2) 

} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"GeoBroadcast forwarding algorithm." 
: := { itsGnPacketForwarding 5 } 

itsGnCeoUnicastCbfMinTime OBJECT-TYPE 

SYNTAX Integer32 {0 . .65635) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Minimum duration a packet shall be buffered in the CBF packet buffer in ms . " 
: := { itsGnPacketForwarding 6 } 

itsGnCeoUnicastCbfMaxTime OBJECT-TYPE 

SYNTAX Integer32 {0 . .65635) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Maximum duration a packet shall be buffered in the CBF packet buffer in ms . " 
: := { itsGnPacketForwarding 7 } 

itsGnDefaultMaxCommunicationRange OBJECT- TYPE 

SYNTAX Integer32 {0 . .65635) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Default theoretical maximum communication range in m." 
: := { itsGnPacketForwarding 8 } 

itsGnGeoAreaLineForwarding OBJECT- TYPE 
SYNTAX INTEGER { 

disabled (0) , 
enabled (1) 

} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Forwarding of GEOBROADCAST/GEOANYCAST packet if GeoAdhoc 
router is located outside the GeoArea." 
: := { itsGnPacketForwarding 9 } 

itsGnUcForwardingPacketBuf ferSize OBJECT- TYPE 
SYNTAX Integer32 {0 . .255) 
UNITS "kByte" 
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MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 

"Forwarding: Size of UC forwarding packet buffer in kByte.' 
: := { itsGnPacketForwarding 10 } 

ItsGnBcForwardingPacketBuf ferSize OBJECT- TYPE 

SYNTAX Integer32 {0. . 65535) 

UNITS "kByte" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Forwarding: Size of BC forwarding packet buffer in kByte.' 
: := { itsGnPacketForwarding 11 } 

itsGnCbfPacketBufferSize OBJECT-TYPE 

SYNTAX Integer32 {0 . . 65535) 

UNITS "kByte" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Forwarding: Size of CBF packet buffer [Kbytes] .." 
: := { ItsGnPacketForwarding 12 } 

itsGnTrafficClassRelevance OBJECT-TYPE 

SYNTAX Integer32 {0 . .7) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Forwarding: Default traffic class Relevance." 
: := { ItsGnPacketForwarding 13 } 

itsGnTrafficClassReliability OBJECT-TYPE 

SYNTAX Integer32 {0 . .3) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

" Forwarding: Default traffic class Reliability." 
: := { ItsGnPacketForwarding 14 } 

itsGnTrafficClassLatency OBJECT-TYPE 

SYNTAX Integer32 {0 . .3) 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 

"Forwarding: Default traffic class Latency." 
: := { ItsGnPacketForwarding 15 } 
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Annex H (informative): 
GeoNetworking data services 



H.1 General 

The GN data service primitives allow entities of ITS transport protocols to send and receive PDUs via the GN_S AP. 



H.2 GN-DATA.request 



The GN-DATA.request primitive is used by the ITS transport protocol entity to request sending a GeoNetworking 
packet. Upon reception of the GN-DATA.request primitive, the GeoNetworking protocol delivers the GeoNetworking 
packet to the LLC protocol entity via the IN_SAP. 

The parameters of the GN-DATA.request are as follows: 

GN-DATA.request { 

Upper protocol entity, 

Packet transport type, 

Destination, 

Communication profile. 

Maximum packet lifetime, (optional) 

Repetition interval, (optional) 

Traffic class. 

Length, 

Data 

) 

The Upper protocol entity parameter specifies whether the primitive was triggered by an ITS Transport protocol 
(e.g. BTP) or by the GeoNetworking to IPv6 Adaptation Sub-Layer (GN6ASL). 

The Packet transport type parameter specifies the packet transport type (GeoUnicast, SHB, TSB, GeoBroadcast, 
GeoAnycast). 

The Destination parameter specifies the destination address for GeoUnicast or the geographical area for 
GeoBroadcast/GeoAnycast. The destination address for GeoUnicast can optionally contain the MID field only; with the 
other fields set to (see figure 3 and table 1). 

The Communication profile parameter determines the LL protocol entity (unspecified, ITS-G5A). 

The Maximum lifetime parameter specifies the maximum tolerable time in [s] a GeoNetworking packet can be buffered 
until it reaches its destination. The parameter is optional. If it is not used, the MIB attribute itsGnMaxPacketLifetime is 
used. 

The Repetition interval paiametei specifies the duration between two consecutive transmissions of the same 
GeoNetworking packet during the lifetime of a packet in [ms]. The parameter is optional. If it is not used, the packet 
should not be repeated. 

The Traffic class parameter specifies the traffic class for the message as a triple of Relevance, Reliability, and Latency. 

The Length parameter indicates the length of the Data parameter. 

The Data parameter represents the payload of the GeoNetworking packet to be sent, i.e. the T-SDU/GN6-SDU. 
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H.3 GN-DATA.confirm 



The GN-DATA.confirm primitive is used to confirm that the GeoNetworking packet was successfully processed in 
response to a GN-D ATA.request. For the reception of the primitive, no behaviour is specified. 

The parameters of the primitive are as follows: 

GN-DATA.confirm { 

ResultCode 
) 

The ResultCode parameter specifies whether the GN-D ATA. request primitive: 

has been accepted; 

rejected due to maximum length exceeded if the size of the T/GN6-PDU exceeds the MIB attribute 
itsGnMaxSduSize; 

reject due to maximum lifetime exceeded if the lifetime exceeds the maximum value of the MIB attribute 
itsGnMaxPacketLifetime ; 

reject due to repetition interval too small, if the repetition interval is smaller than the MIB attribute 
itsGnMinPacketRepetitionlnterval; 

rejected due to unsupported traffic class; or 

rejected for unspecified reasons if the GN-D ATA. re quest primitive cannot accepted for any other reason. 



H.4 GN-DATA.indication 



The GN-DATA.indication primitive indicates to an upper protocol entity that a GeoNetworking packet has been 
received. The primitive is generated by the GeoNetworking protocol to deliver data contained in a received 
GeoNetworking packet to upper protocol entity. The data of the GeoNetworking packet are processed as determined by 
the receiving upper protocol entity. 

The parameters of the GN-DATA.indication primitive are as follows: 

GN-DATA.indication { 

Upper protocol entity. 

Packet transport type. 

Destination 

Source position vector. 

Traffic class. 

Remaining packet lifetime (optional) , 

Length, 

Data -- T/GN6-PDU 

) 

The Upper protocol entity parameter determines the protocol entity that processes the service primitive (BTP or GN6). 

The Packet transport type parameter is the packet transport type (GeoUnicast, SHB, TSB, GeoBroadcast, GeoAnycast) 
of the received packet. 

The Destination parameter is the destination address for GeoUnicast or the geographical area for 
GeoBroadcast/GeoAnycast, with which the GeoNetworking packet was generated by the source. 

The Source position vector parameter is the geographical position for the source of the received GeoNetworking packet. 

The Remaining packet lifetime parameter is the remaining lifetime of the packet. 

The Traffic Class parameters is the traffic class, with which the GeoNetworking packet was generated by the source. 

The Length parameter is the length of the Data parameter. 

The Data parameter is the payload of the received GeoNetworking packet, i.e. the T-PDU/GN6-PDU. 
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Annex I (informative): 
GeoNetworking management services 

1.1 General 

The GN management service primitives allow the ITS Network and Transport Layer Management entity to update 
position, time and GeoNetworking address of the GeoAdhoc router. 



1.2 GN-IVIGIVIT. request 



The GN-MGMT.request primitive is generated by the GeoNetworking protocol entity at the initialization phase in order 
to request management information, i.e. time, position vector, GeoNetworking address. After receiving the 
GN-MGMT.request primitive, the ITS Network and Transport Layer Management entity is in charge of providing the 
GeoNetworking entity with the requested management information. 

The parameters of the GN-MGMT.request are as follows: 

GN-MGMT.request { 

Request cause 
) 

The Request cause parameter specifies the type of requested information, i.e. time, position vector, GeoNetworking 
address. In case the GeoNetworking address is requested, the parameter also indicates whether the address request is 
caused by duplicate address detection or is an initial request. 



1.3 GN-IVIGIVIT.response 



The GN-MGMT.response primitive is generated by the ITS Network and Transport Layer Management entity to 
indicate an update of management information, i.e. time, position vector and GeoNetworking address. The primitive can 
be triggered upon reception of a GN-MGMT.request primitive or can be generated unsolicited, i.e. without a 
GN-MGMT.request primitive. 

The parameters of the GN-MGMT.response are as follows: 

GN-MGMT.response { 

Time (optional) 

Local position vector (optional) 

GeoNetworking address (optional) 

) 

The Time parameter specifies the timestamp that is used as a reference to determine the freshness of received 
information carried in packets. 

The Local position vector parameter specifies the ITS station's most recent position vector (geographical position, 
speed, heading, timestamp when the position vector was generated, and corresponding accuracy information). 

The GeoNetworking address parameter specifies the GeoNetworking address that shall be used by the GeoNetworking 
protocol entity. 

All parameters are optional, whereas at least one parameter should be present. 
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